canonical이 여러 개 있을 때 생기는 일

복수 선언의 지원과 주소 충돌

구글 검색 센터는 HTML의 대표 주소 태그와 HTTP 헤더를 함께 사용할 수 있다고 설명하면서도, 둘 중 하나를 선택해 지속적으로 사용하도록 권장합니다. 사이트 운영자는 선언이 여러 곳에 있다는 사실만으로 오류를 판정하지 말고, 각 선언이 어떤 주소를 알리는지 개발 담당에게 요청해야 합니다.

대표 주소 태그는 페이지의 HTML 안에 있고, HTTP 헤더는 서버가 페이지를 전달할 때 보내는 응답 정보입니다. 화면에 표시되는 문구나 관리자 입력란만으로는 두 위치에 어떤 값이 전달되는지 알기 어려우므로, 실제 출력된 HTML과 서버 응답을 함께 요청합니다.

여러 페이지와 한 페이지의 차이

여러 페이지가 같은 대표 주소를 알리는 상황과 한 페이지가 여러 곳에서 대표 주소를 선언하는 상황은 서로 다른 판단 대상입니다. 이번에 가려야 할 문제는 한 페이지의 HTML과 HTTP 헤더가 같은 결정을 전달하는지입니다.

여러 페이지를 모은 목록에서 동일한 대표 주소가 반복된다고 해서 한 페이지에 선언이 중복된 것은 아닙니다. 개발 담당에게 자료를 요청할 때는 조사 대상 페이지를 기준으로 선언 위치와 값을 연결해 기재하도록 요청합니다.

표는 예상한 설정값이 아니라 실제로 전달되는 값을 기록하는 용도로 사용합니다. 선언을 찾지 못한 위치는 빈칸으로 남기지 않고, 미수집인지 해당 선언이 없는 상태인지 따로 기재합니다.

주소가 일치할 때와 다를 때의 판단

같은 주소를 알리는 병용과 서로 다른 주소를 알리는 충돌은 처리 이유가 다릅니다. 전자는 관리할 선언 방식을 정리하는 문제이고, 후자는 의도한 대표 주소를 확정한 뒤 잘못 전달되는 값을 고치는 문제입니다.

구글 검색 센터는 HTTP 헤더와 HTML의 대표 주소 태그가 서로 다른 주소를 제공하는 상황을 오류의 예로 설명합니다. 이 설명만으로 복수 선언이 반드시 모두 무시된다거나 어느 위치의 선언이 항상 우선한다고 단정할 수는 없습니다.

운영자는 오류를 발견했다는 이유만으로 눈에 잘 띄는 태그부터 삭제하지 않습니다. 어느 주소를 유지할지와 어느 설정을 변경할지를 분리해서 결정한 뒤 개발 담당에게 전달합니다.

선언 위치별 자료 요청 순서

개발 담당에게는 대표 주소 설정의 유무보다 선언 위치별 실제 값을 요청합니다. 마케팅 담당자는 조사 대상 페이지와 의도한 대표 주소를 준비하고, 개발 담당자는 HTML과 서버 응답에서 찾은 선언을 같은 목록에 기재합니다.

1. 선언 위치를 파악합니다. HTML의 대표 주소 태그와 HTTP 헤더를 각각 조사하고, 해당 값을 만드는 설정이나 코드도 함께 기록합니다.
2. 위치별 대표 주소를 대조합니다. 주소 전체를 생략 없이 수집하고, 서로 다른 부분이 있으면 그 차이를 표시합니다.
3. 선언 방식의 일관성을 정리합니다. 유지할 방식과 제거하거나 변경할 설정을 정하고, 각 작업의 담당자를 명시합니다.

주소를 화면용으로 줄여 표시한 자료만 받으면 실제 차이를 놓칠 수 있습니다. 개발 담당에게는 원래 값을 보존한 자료를 요청하고, 보고용 목록에는 일치 여부와 판단에 필요한 차이만 요약합니다.

관리자에 입력한 값과 실제 출력값이 다르다면 입력란만 고치는 요청으로 끝내지 않습니다. 개발 담당이 출력에 관여하는 설정을 찾아 어떤 변경이 필요한지 설명하도록 요청합니다.

상태에 따른 정리 요청

정리 요청은 현재 상태에 따라 다르게 작성합니다. 아래 표의 제안은 운영 업무를 정돈하기 위한 방법이며, 구글이 선언을 처리하는 우선순위를 뜻하지 않습니다.

한 가지 방식으로 정리할 때는 삭제 대상만 전달하지 말고 유지할 선언 위치와 대표 주소도 함께 명시합니다. 개발 담당은 해당 요청이 공통 설정을 변경하는지 특정 페이지의 설정만 변경하는지 설명해야 합니다.

공통 설정을 수정하면 조사 대상 이외의 페이지에도 변경이 적용될 수 있습니다. 운영자는 작업 전에 적용 범위를 요청하고, 범위가 다른 항목은 같은 수정 요청에 섞지 않습니다.

변경 요청서에는 현재 값, 유지할 값, 변경 대상, 처리 담당을 연결해 기록합니다. 개발 담당이 선택한 방식으로 관리하기 어렵다고 답하면 제약 사유를 받은 뒤 정리안을 조정합니다.

선언 수만으로 내리는 오판

복수 선언에서 자주 생기는 실수는 선언 수를 오류 판정 기준으로 사용하는 것입니다. 같은 주소를 전달하는지 조사하기 전에 모두 삭제하거나 특정 위치만 남기면, 의도한 대표 주소까지 함께 제거할 수 있습니다.

HTML에서 태그를 찾았다는 이유로 HTTP 헤더 조사를 생략하는 것도 피해야 합니다. 화면이나 HTML 편집 기능만 다루는 담당자는 서버 응답의 설정을 직접 관리하지 않을 수 있으므로, 필요한 자료를 누가 수집할지 먼저 정합니다.

반대로 HTTP 헤더에 값이 있다는 이유만으로 HTML의 선언을 무조건 불필요하다고 판단하지 않습니다. 앞에서 정한 기준에 따라 유지할 방식을 선택하고, 실제로 제거할 설정과 담당자가 관리할 수 있는 설정이 같은지 따집니다.

설정값과 검색 도구 기록의 역할

서치 콘솔에 표시된 대표 주소만으로 선언 위치별 조사를 대신할 수는 없습니다. 구글의 서치 콘솔 도움말은 운영자가 선언한 주소와 구글이 선택한 주소를 각각 설명하므로, 두 항목을 같은 의미로 해석하지 않습니다.

구글은 운영자가 선호하는 대표 주소를 고려하지만 그 주소를 반드시 선택한다고 보장하지는 않는다고 설명합니다. 개발 담당에게 보내는 수정 요청에는 검색 도구의 결과만 넣지 말고, 실제 선언값과 운영자가 유지하려는 값을 함께 기재합니다.

구글의 서치 콘솔 도움말에 따르면 실시간 테스트는 대표 주소 선택과 관련된 모든 조건을 시험하지 않습니다. 실시간 테스트에서 등록 가능한 상태로 표시됐다는 이유만으로 선언 충돌이 해결됐다고 결론 내리지 않습니다.

업무 기록에서는 실제 출력값, 요청한 변경값, 검색 도구에 표시된 값을 별도 항목으로 관리합니다. 서로 다른 자료를 한 칸에 덮어쓰면 설정 오류인지 결과 해석의 문제인지 가리기 어려워집니다.

선언을 만드는 기능의 중복

대표 주소 태그를 삭제했는데 다시 출력된다면, 삭제한 태그 외에 같은 선언을 만드는 기능이 있는지 개발 담당에게 요청합니다. 관리자 설정, 공통 템플릿, 별도 확장 기능 등 실제 사이트에서 사용하는 출력 경로를 조사 대상으로 삼습니다.

출력된 결과만 지우고 생성 설정을 그대로 유지하면 이후 수정이나 배포 과정에서 선언이 다시 추가될 수 있습니다. 개발 담당은 유지할 출력 경로와 변경할 경로를 명시하고, 운영자는 다음 관리 작업에서도 같은 기능을 중복 사용하지 않도록 설정 담당을 정합니다.

기능 이름이 다르다는 사실만으로 서로 독립된 선언이라고 판단하지 않습니다. 각 기능이 최종 응답의 어느 위치에 값을 넣는지 연결해서 기록합니다.

이어서 읽을 주제

병원 사이트 색인은 선언한 대표 주소와 검색 도구의 색인 상태를 함께 해석하려는 독자가 이어 읽을 주제입니다. 병원 홈페이지 리뉴얼은 사이트 개편 때 기존 설정을 누가 인계받고 어떤 출력 기능을 유지할지 정하려는 독자가 이어 읽을 주제입니다.