URL별 결과를 채우는 점검표 구성
리뉴얼 SEO 점검표는 옛 URL의 새 목적지와 이동 응답, 새 문서의 표준 지정·공개 지시·내부 링크를 연결해 검사하는 실행표로 구성합니다. 각 주소에서 실제로 얻은 증거와 실패 상태를 구분하고, 수정 담당과 다시 검사할 날짜를 함께 넣을 수 있습니다. 정상 HTTP 응답이나 체크 표시를 검색 색인 완료와 같은 상태로 표시하지 않습니다.
Google의 이동 지침은 리디렉션을 URL 검사 도구로 하나씩 시험하거나 명령줄 도구·스크립트로 여러 URL을 시험하는 방법을 설명합니다. 따라서 아래 양식의 한 행은 실제 시험한 주소와 항목을 나타내도록 채웁니다. 다른 문서에서 얻은 결과를 조사하지 않은 주소의 합격 증거로 옮겨 적지 않는 적용 방식입니다.
주소별 결과를 채우는 실제 빈 양식
| URL | 검사 항목 | 실제 증거·실패 상태 | 수정 담당 | 재검사일 |
|---|---|---|---|---|
| 실제 옛 주소 입력 | 실제 이동 검사 대상 입력 | 실제 요청 결과 입력 | 실제 담당 입력 | 실제 일정 입력 |
| 실제 새 주소 입력 | 실제 표준·공개 조건 입력 | 실제 문서 결과 입력 | 실제 담당 입력 | 실제 일정 입력 |
| 실제 연결 문서 입력 | 실제 내부 링크 대상 입력 | 실제 연결 결과 입력 | 실제 담당 입력 | 실제 일정 입력 |
새 목적지의 실제 내용으로 대응을 판단하기
옛 주소의 목적지를 검사할 때에는 이동에 성공했다는 상태와 관련 문서에 도착했다는 상태를 나눕니다. Google은 관련 없는 홈페이지 같은 한 주소로 여러 옛 URL을 보내면 soft 404로 처리될 수 있다고 설명합니다. 점검표에서 새 주소가 열린다는 한 결과만 채우면 이런 잘못된 대응을 발견하기 어렵습니다.
반면 여러 페이지의 콘텐츠를 실제 하나의 새 문서에 통합한 경우에는 여러 옛 URL을 그 문서로 이동시킬 수 있습니다. 따라서 옛 주소와 새 주소가 일대일이 아니라는 이유만으로 실패라고 표시하지 않습니다. 실제 보존된 내용과 이동 목적지의 관계를 검사해 해당 행의 결과를 판단합니다.
이동 응답과 도착 문서 응답을 분리하기
가능하면 서버 측 영구 리디렉션을 사용하도록 사이트 이동 안내는 권장합니다. 301·308 같은 영구 응답이 실제로 제공되는지 읽어야 하며, 사용자의 화면이 다른 주소로 전환됐다는 결과만으로 응답 종류를 판단하지 않습니다. 옛 URL의 응답을 조사하는 칸과 최종 문서의 응답을 조사하는 칸을 나눠 사용하는 방식입니다.
HTTP 안내는 리디렉션 주소에서 받은 내용을 무시하고 최종 대상 주소의 콘텐츠를 처리한다고 설명합니다. 점검 결과에서 중간 응답의 본문과 최종 문서의 본문을 혼동하면 내용 보존 여부가 달라질 수 있습니다. 실제 최종 도착 문서를 읽고 이전하려던 내용이 제공되는지 조사해야 합니다.
리디렉션 체인을 길게 만들기보다 최종 목적지로 직접 연결하는 것이 좋다는 이동 지침도 적용할 수 있습니다. 여러 이동을 거칠 때에는 사용자의 지연 시간이 늘 수 있고 일부 사용자 에이전트나 브라우저가 긴 체인을 지원하지 않습니다. 목적지 주소가 맞는지와 도착 과정에서 몇 번 이동하는지의 증거를 구분해 읽습니다.
표준 지정과 사이트 안의 연결을 함께 조사하기
새 URL마다 자체 참조 canonical을 지정하는 단계가 Google 이동 지침에 있습니다. 실제 새 문서가 자기 주소를 대표 주소로 제시하는지 조사합니다. 표준 문서 안내는 다른 표준화 방법들이 서로 다른 URL을 같은 페이지의 대표 주소로 지정하지 않도록 설명합니다. 사이트맵의 선호 주소와 문서의 표준 지정이 서로 일치하는지도 대상이 됩니다.
내부 링크는 새 URL로 갱신해야 합니다. 표준화 안내 역시 사이트 안에서 중복 URL 대신 표준 URL에 일관되게 연결하도록 설명합니다. 새 문서 자체의 표준 주소가 맞더라도 다른 문서의 내부 링크가 옛 주소를 계속 사용한다면 검사 대상이 다릅니다. 한 문서의 코드 결과를 사이트의 모든 연결 결과로 확대하지 않습니다.
JavaScript로 화면을 구성하는 경우 표준 정보를 가능한 명확하게 제공해야 합니다. 공식 안내는 HTML 소스에서 표준 URL을 지정하고 JavaScript가 표준 링크 요소를 변경하지 않는 방법을 설명합니다. HTML 소스에서 지정할 수 없다면 JavaScript만으로 설정할 수 있습니다. 최초 소스의 값과 실행 후 변경된 값이 충돌하는지 구별해야 하는 조건입니다.
표준 주석에 언어·미디어·파일 형식의 속성을 추가한 결과를 표준화 신호로 판단하지 않아야 합니다. Google은 canonical에 있는 lang·media·type 속성을 표준화에 사용하지 않는다고 설명합니다. 대체 버전의 표시에는 적절한 별도 링크 주석을 사용해야 하므로, 표준 URL을 읽는 검사와 대체 버전의 주석을 읽는 검사의 대상을 구분합니다.
표준 주석 구현의 별도 검사 조건
| 구현 조건 | 공식 기준 | 판단할 결과 |
|---|---|---|
| HTML 표준 요소의 위치 | 유효한 head에 포함될 때 허용 | 문서 위치와 HTML 유효성 |
| HTML 요소와 HTTP 헤더의 병용 | 서로 다른 URL이면 오류 발생 | 두 방식의 실제 대상 일치 |
| 표준 요소의 경로 형태 | 상대보다 절대 경로 권장 | 시험 환경으로 잘못 연결되는 위험 |
준비용 차단과 대표 주소 선택을 혼동하지 않기
Google의 이동 지침은 새 URL이 너무 일찍 색인되는 것을 막으려고 noindex를 넣었다면 이동 적용 뒤 그 규칙을 갱신하도록 설명합니다. 새 주소의 공개 검사를 할 때에는 실제 문서에 남은 지시를 읽어야 합니다. 준비 단계에서 의도한 차단과 공개 뒤의 상태가 같아야 한다고 가정하지 않습니다.
한 사이트 안의 대표 주소를 선택하려는 목적으로 noindex를 사용하는 것도 권장되지 않습니다. 표준화 문서에 따르면 페이지가 검색에서 완전히 차단될 수 있기 때문입니다. 검색에서 제외할 문서를 정하는 일과 여러 중복 문서의 대표를 지정하는 일은 다른 조건으로 점검표에 적용합니다.
robots.txt 역시 표준 지정 수단으로 사용해서는 안 됩니다. Google은 크롤링이 허용되지 않는 URL을 콘텐츠 없이 색인할 수 있다고 설명합니다. robots.txt의 접근 제한을 적용한 상태만으로 원한 대표 주소가 선택됐다고 결과를 표시하지 않습니다. 표준화와 접근 가능성을 각각의 실제 결과로 판단하는 조건입니다.
URL 삭제 도구를 대표 주소 선택을 위한 표준화 수단으로 사용하는 것도 피해야 합니다. 공식 표준화 안내는 이 도구가 Google 검색에서 모든 버전의 URL을 숨긴다고 설명합니다. 중복 문서 가운데 선호 버전을 제시하려던 검사 목표와 모든 버전을 숨기는 결과가 같지 않습니다. 점검표를 적용할 때 실제 설정의 목적과 도구의 결과를 먼저 구분해야 합니다.
정상 코드와 실제 콘텐츠를 나눠 읽기
서버가 200으로 응답하면 콘텐츠는 다음 처리 단계로 전달됩니다. 그러나 HTTP 안내는 빈 페이지나 오류 메시지를 제공하면 soft 404가 표시될 수 있다고 설명합니다. 리뉴얼 문서가 정상 코드로 열리는지와 필요한 설명을 실제 제공하는지 나눠 조사해야 합니다. 오류 안내가 정상 코드로 반환되는 경우도 내용 검사가 필요합니다.
색인 시스템에서 콘텐츠를 색인할 수 있지만 200 응답만으로 색인이 확정되지는 않습니다. 점검표의 기술 검사 결과와 검색에서의 처리 상태가 다른 이유입니다. 한 주소의 구현 상태를 특정 검색 순위나 병원 방문수의 약속으로 바꾸어 해석하지 않습니다.
Search Console은 4xx·5xx 상태나 실패한 리디렉션에 대한 오류 메시지를 생성한다고 HTTP 안내는 설명합니다. 실패 표시가 있다면 어떤 주소의 어떤 요청에서 발생했는지 실제 자료를 읽어야 합니다. 옛 주소의 이동 오류와 새 문서의 응답 오류를 같은 원인으로 처리하지 않습니다.
수정한 항목을 다시 시험하는 양식으로 사용하기
실패를 발견한 행에는 실제 오류의 증거와 이를 수정할 주체를 연결할 수 있습니다. 이 담당·재검사일 양식은 병원의 작업을 정리하기 위한 제안이며 Google이 지정한 인력이나 일정은 아닙니다. 실제 수정 권한과 합의한 작업 범위를 바탕으로 채워야 합니다.
수정 전의 실패 자료를 그대로 최신 결과로 쓰지 않고 수정 후 같은 대상의 요청과 문서 상태를 다시 시험합니다. Google이 안내하는 개별 URL 검사 또는 다수 URL 시험을 실제 수정 대상에 적용하는 방법입니다. 수정하겠다는 계획, 설정을 적용한 상태, 다시 시험해 얻은 결과를 같은 완료 표시로 처리하지 않는 실행 기준입니다.
자주 묻는 질문
표준 주소에 페이지 안의 위치 표시를 넣어도 되나요?
Google은 일반적으로 URL 프래그먼트를 지원하지 않으므로 이를 표준 URL로 지정하지 않도록 설명합니다. 같은 문서 안의 특정 위치를 가리키는 표시와 대표 문서의 주소를 구별해야 합니다.
PDF도 HTML의 표준 요소로 검사하나요?
HTML의 link 요소는 PDF 같은 파일에 작동하지 않습니다. 서버 구성을 변경할 수 있다면 HTTP 응답 헤더로 HTML이 아닌 문서의 표준 URL을 표시할 수 있습니다. Google은 이 방법을 웹 검색결과에 지원합니다.
언어별 문서의 표준에는 별도 조건이 있나요?
hreflang을 사용한다면 같은 언어로 표준 페이지를 지정합니다. 같은 언어의 표준 문서가 없으면 가장 유사한 언어의 표준 문서를 지정하라고 안내합니다. 실제 언어별 구성이 있는 경우의 조건입니다.
304 응답은 문서 내용을 새로 보냈다는 뜻인가요?
Google 크롤러는 콘텐츠가 마지막 크롤링 때와 동일하다고 다음 처리 시스템에 알립니다. 검색의 색인 시스템에서 URL 신호를 다시 계산할 수 있지만 새 내용이 전달됐다는 결과로 이해하지 않습니다.
429와 다른 4xx는 같은 실패 원인인가요?
Google은 429를 서버 과부하의 신호로 취급해 서버 오류로 처리합니다. 다른 4xx의 콘텐츠 부재와 구분하며 응답을 반환한 실제 환경에서 원인을 조사해야 합니다.