서치콘솔 HTML 태그 인증 실패: 워드프레스 head 출력 확인법

인증 코드를 저장했는데도 서치콘솔에서 태그를 찾지 못한다면, 입력한 설정과 방문자에게 전달되는 HTML을 나눠 확인해야 합니다. 워드프레스에서는 설정을 저장한 플러그인, 테마의 출력 경로, 캐시가 서로 다른 지점에서 작동할 수 있습니다.

실제 사례: DNS 대신 HTML 태그를 사용한 작업

2026년 4월 완료 기록에는 DNS 인증을 진행할 수 없는 상황에서 HTML 태그 방식을 선택하고, 테마의 head 출력 경로를 확인해 인증 태그용 별도 플러그인을 제작한 내용이 남아 있습니다. 사이트맵과 RSS 제출도 작업 항목에 포함됐습니다.

1. 속성 유형부터 확인합니다

DNS 권한이 없다면 URL 접두어 속성에서 태그 방식을 검토합니다. 이 속성은 프로토콜과 호스트가 일치해야 하므로 http://example.com/, https://example.com/, https://www.example.com/을 구분합니다. 여러 프로토콜·하위 도메인을 포함하는 도메인 속성과 범위가 다릅니다. 기준은 Google 속성 유형 문서입니다.

2. 로그아웃한 홈페이지의 head를 봅니다

1. 서치콘솔에 등록한 주소를 시크릿 창에서 엽니다. 로그인 없이 접근되는지, 이동 후 최종 주소가 무엇인지 확인합니다.
2. 그 페이지의 페이지 소스 보기에서 google-site-verification을 찾습니다. <head> 안에 있고 인증 화면의 content 값과 같은지 비교합니다.
3. 태그가 없다면 관리자에서 입력한 값만 다시 보지 말고 실제 출력 경로를 추적합니다. 본문 편집기의 HTML 블록이나 푸터에 넣은 태그로 끝내지 않습니다.

아래는 형태를 보여 주는 예시입니다. PASTE_YOUR_TOKEN_HERE는 인증값이 아닙니다. 본인 계정의 인증 화면에서 제공된 값을 사용해야 합니다.

<meta name="google-site-verification"
      content="PASTE_YOUR_TOKEN_HERE" />

태그 방식은 등록 주소가 이동시키는 비로그인 최종 페이지를 확인하며, 인증 후에도 태그를 유지해야 합니다. Google의 태그 위치·유지 조건을 참고하세요.

3. 기존 설정 → 캐시 → 테마 순서로 좁힙니다

먼저 태그를 관리하는 곳을 하나 정합니다

사용 중인 SEO 플러그인이나 사이트 연결 도구에 이미 인증 설정이 있는지 확인합니다. 입력칸이 태그 전체를 받는지, content 값만 받는지는 해당 도구의 안내를 따릅니다. 같은 값을 여러 삽입 플러그인과 테마에 중복해서 넣으면 나중에 수정할 위치를 찾기 어렵습니다.

여러 소유자의 서로 다른 태그가 있을 수도 있습니다. 태그가 여러 개라는 이유만으로 다른 소유자의 값을 지우지 말고, 현재 인증하려는 값의 존재 여부부터 확인하세요. 삭제 전에는 소유자와 관리 목적을 구분합니다.

저장은 됐는데 공개 소스가 다를 때

페이지 캐시, 호스팅 캐시, CDN을 사용한다면 변경한 홈페이지의 캐시를 각 계층에서 갱신하고 다시 소스를 확인합니다. 로그인한 관리자에게만 새 HTML이 보이고 일반 방문자에게는 이전 응답이 남아 있을 수 있습니다. 전체 캐시 기능을 영구적으로 끄는 조치는 필요하지 않습니다.

캐시를 갱신해도 태그가 나오지 않으면 실제 홈페이지가 워드프레스 템플릿을 거치는지, 다른 정적 첫 화면이나 별도 헤더를 쓰는지 확인합니다. 클래식 테마에서는 활성 템플릿의 </head> 앞에서 wp_head()가 호출되는지 살펴봅니다. 블록 테마는 같은 파일 구조라고 가정하지 말고 실제 렌더링 경로를 확인해야 합니다.

wp_head는 프런트엔드의 head 영역에 데이터를 출력하는 훅입니다. 그 훅이 실행되지 않는 페이지에서는 콜백 플러그인을 추가해도 태그가 나오지 않습니다. 누락이 확인되면 테스트 환경에서 테마의 정상 출력 경로를 복구한 뒤 확인하고, 이미 있는 호출을 중복 삽입하지 않습니다. 근거: WordPress wp_head 문서.

4. 별도 플러그인이 필요한 경우의 최소 예시

기존 설정으로 관리할 수 없고 wp_head()의 정상 실행을 확인한 경우에만 검토할 예시입니다. 고객에게 납품한 소스가 아닙니다. 기본 플러그인 경로를 사용하는 단일 사이트 기준으로 wp-content/plugins/congdy-verification-example/congdy-verification-example.php에 저장하는 구조입니다.

<?php
/**
 * Plugin Name: Congdy Verification Example
 * Description: Educational verification-tag example.
 * Version: 1.0.0
 */
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_action( 'wp_head', function () {
    $token = 'PASTE_YOUR_TOKEN_HERE';

    if ( '' === $token ||
         'PASTE_YOUR_TOKEN_HERE' === $token ) {
        return;
    }

    printf(
        '<meta name="google-site-verification" content="%s" />' . "\n",
        esc_attr( $token )
    );
}, 5 );

플러그인을 인식시키는 주석은 WordPress 플러그인 헤더 규칙을 따릅니다. $token에는 태그 전체가 아닌 content 값만 넣습니다. 자리표시자를 바꾸지 않으면 아무것도 출력하지 않도록 했습니다. 출력 시에는 esc_attr()로 HTML 속성값을 처리합니다.

백업과 원복 경로를 확보하고 테스트 환경에서 PHP 문법, 활성화, 공개 HTML을 확인한 뒤 적용하세요. 기존 테마 파일 전체에 덮어쓰거나 다른 PHP 파일 아래에 이 예시를 그대로 이어 붙이지 않습니다. 사이트마다 토큰을 따로 관리해야 하므로 여러 사이트에 같은 파일을 일괄 배포하는 용도도 아닙니다.

이 예시는 정상 훅을 이용하는 출력 방식일 뿐, 누락된 테마 훅을 보완하거나 캐시를 자동 갱신하거나 소유권 인증을 대신 수행하지 않습니다. 운영 적용 후 오류가 나면 새 플러그인을 비활성화하고 백업 상태로 되돌린 뒤 원인을 확인합니다.

5. 작업 완료는 네 단계로 확인합니다

• 출력: 로그아웃한 최종 홈페이지 소스에 본인의 정확한 태그가 있는지 확인하고, 확인 시각과 관리 위치를 남깁니다.
• 인증: 해당 속성에서 확인을 실행해 성공 표시를 직접 확인합니다. 화면을 확인하지 않았다면 “태그 출력 확인”까지만 보고합니다.
• 회귀 점검: 홈페이지와 대표 상세 페이지를 열어 레이아웃·로그인 등 기존 기능이 유지되는지 확인합니다. 테마 출력을 수정했다면 관련 스크립트와 스타일도 살핍니다.
• 유지: 테마 교체, 플러그인 정리, 캐시 설정 변경 후에도 같은 확인을 반복합니다. 담당자가 바뀔 때는 태그 관리 위치와 소유자를 함께 인계합니다.

“태그를 못 찾음”이라면 최종 페이지와 head 출력을, “값이 다름”이라면 현재 계정의 값을 먼저 확인합니다. 연결 실패라면 도메인 응답·리디렉션·접근 제한을 따로 점검하고 방화벽을 통째로 해제하지 않습니다.

6. 사이트맵·RSS 제출은 인증 다음의 별도 작업입니다

사례 기록에 포함된 사이트맵과 RSS 제출은 소유권 인증과 구분해야 합니다. 사이트가 실제로 제공하는 XML 사이트맵 주소를 확인해 제출하고, 서치콘솔의 처리 결과와 오류를 따로 봅니다. 사용 중인 SEO 도구가 생성하는 주소를 먼저 확인하세요.

Google은 RSS 2.0과 Atom 1.0 피드를 사이트맵으로 받을 수 있지만, 피드에는 보통 최근 URL만 들어 있습니다. RSS 제출만으로 전체 페이지 목록을 제출했다고 판단하면 안 됩니다. 사이트맵 제출 또한 Google의 다운로드·크롤링을 보장하지 않습니다. Google 사이트맵 작성·제출 문서에 설명된 범위입니다.

따라서 완료 보고는 태그 출력 확인 / 소유권 인증 확인 / 사이트맵 제출·처리 상태를 나눠 작성하는 편이 정확합니다. 인증과 제출을 마쳤다는 이유로 검색 색인이나 상위 노출까지 완료됐다고 안내하지 않습니다.

함께 볼 글: 하위 폴더 설치와 공개 주소 설정 · 403 차단과 플러그인 문제 구분 · 업데이트 후 오류 복구 순서

작성·공식 문서 확인: 2026년 11월 6일. 고객 식별 정보와 인증값은 공개하지 않았습니다.