기술 SEO 점검 순서: 크롤링, 색인, 렌더링과 사이트 구조

빨간 경고가 수백 개 표시된 SEO 보고서를 받으면 용어를 이해하는 것보다 무엇을 먼저 고칠지 판단하는 일이 더 어려울 수 있습니다. 홈페이지가 열리지 않는 문제, 설명이 없는 이미지 하나, 속도 측정 점수가 몇 점 낮은 문제는 독자와 사이트에 미치는 영향이 서로 다릅니다.

기술 SEO는 콘텐츠가 검색 과정에 들어가기 전의 기본 점검으로 볼 수 있습니다. URL을 찾을 수 있는지, 응답이 올바른지, 주요 내용을 읽을 수 있는지, 여러 버전이 적절한 위치를 가리키는지 살핍니다. 이 글은 각 문제의 범위, 근거, 완료 기준을 갖춘 감사 절차로 정리해 유지관리 담당자가 실제 작업으로 옮길 수 있게 합니다.

먼저 사이트 범위와 대표 페이지 정하기

제과 공방의 웹사이트 개편을 예로 들면 홈페이지, 강좌 목록, 개별 강좌, 글, 문의 페이지, 회원 영역이 있을 수 있습니다. 어떤 페이지를 공개 검색 대상으로 삼고 어떤 페이지를 로그인한 수강생에게만 제공할지 먼저 표시하세요. 회원 영역이 색인에 없다면 설계대로 작동하는 것일 수 있으므로 색인되지 않은 모든 URL을 오류로 분류해서는 안 됩니다.

페이지 템플릿별로 대표 URL을 고른 뒤 최근에 만들거나 옮겼거나 오류가 있었던 페이지를 추가합니다. 강좌 템플릿에서는 모집 중인 강좌와 종료된 강좌를 하나씩, 글에서는 도표가 있는 글과 텍스트만 있는 글을 각각 고릅니다. 표본 점검은 공통 템플릿의 문제를 찾기 위한 것이지 페이지 하나가 정상이라고 사이트 전체를 정상으로 추정하기 위한 것이 아닙니다.

작업표에는 최소한 URL, 페이지 유형, 공개 목적, 점검 시간, 발견한 문제, 영향 범위를 기록하세요. 개편 중 테마, 플러그인, 도메인, 경로 가운데 무엇을 바꿨는지도 적습니다. 그러면 이후의 이상 현상을 실제 변경 사항과 비교할 수 있어 가능한 모든 원인을 처음부터 추측하지 않아도 됩니다.

첫 번째 단계: 올바른 콘텐츠를 가져올 수 있는지 확인

Google의 기본 기술 요건에는 크롤러를 차단하지 않을 것, 페이지가 성공 응답을 반환할 것, 색인을 생성할 수 있는 콘텐츠가 있을 것이 포함됩니다. 요건을 충족해도 색인은 보장되지 않습니다. 그러나 공개하려는 강좌 페이지가 오류를 반환하거나 로그인을 요구한다면 이 진입 장애부터 해결해야 합니다. 검색결과의 모습보다 먼저 실제로 내용을 이용할 수 있게 만드세요.

로그아웃한 창에서 대표 URL을 열어 올바른 페이지가 보이는지 확인하고, 유지관리 담당자에게 HTTP 상태 코드, 리디렉션, 방화벽 응답도 확인해 달라고 요청하세요. 화면에 강좌명이 나온다고 서버 응답까지 올바르다는 뜻은 아닙니다. 반대로 성공 응답을 돌려주어도 빈 화면이나 인증 화면만 보인다면 실제 독자의 읽기 요구를 충족하지 못합니다.

사이트 전체, 특정 템플릿, 개별 페이지의 문제를 구분하세요. 모든 강좌 페이지가 로그인 화면으로 이동한다면 공통 권한 설정을 확인하고, 오래된 강좌 하나만 실패한다면 그 경로의 연결을 조사합니다. 리디렉션을 고친 뒤 방문자가 또 다른 순환 경로로 들어가지 않도록 원래 URL과 최종 도착지도 모두 보관하세요.

두 번째 단계: 색인 지시문과 버전 선택 확인

페이지의 robots 메타 태그, 관련 응답 헤더, robots.txt를 확인하여 의도한 공개 범위와 일치하는지 살펴보세요. 시험용 사이트에는 색인 차단 설정이 자주 있습니다. 개편한 사이트를 공개하기 전에 다시 확인하지 않으면 실제 사이트의 글까지 색인에서 제외될 수 있습니다. 관리자 화면의 설정을 껐다는 사실만 믿지 말고 실제 응답을 확인하세요.

같은 콘텐츠를 제공하는 여러 URL에 대해서는 canonical 선언, Sitemap, 내부 링크, 리디렉션이 서로 일치하는지 확인합니다. Google은 이를 강도가 서로 다른 표준화 신호로 취급하며 사이트의 지정이 절대적인 명령은 아닙니다. Sitemap에는 한 버전을 나열하면서 페이지는 다른 버전을 지정하거나, 서로 다른 강좌를 모두 홈페이지로 가리키는 일을 피하세요.

Search Console에서 색인에 등록된 버전의 표준 URL 정보를 확인하고 실시간 테스트로 현재 페이지를 점검합니다. 두 도구는 서로 다른 시점에 관한 질문에 답합니다. Google 문서에 따르면 실시간 테스트는 Google이 최종적으로 선택할 표준 버전을 예측하지 못합니다. 완료 기준에는 현재 출력이 수정됐는지와 색인 데이터가 갱신됐는지를 따로 기록하세요.

세 번째 단계: 실제 렌더링과 사이트 내부 경로 확인

주요 콘텐츠를 JavaScript로 불러온다면 렌더링된 HTML, 화면, 로드에 실패한 리소스를 확인하세요. Google이 JavaScript를 실행할 수 있어도 차단된 리소스나 코드 오류 때문에 문제가 생길 수 있고, 다른 도구에는 같은 기능이 없을 수도 있습니다. 자신의 컴퓨터에 페이지가 이전에 로드된 적이 있다고 처음 방문하는 모든 사람도 같은 내용을 본다고 판단해서는 안 됩니다.

제과 강좌 페이지라면 강좌명, 시간, 장소, 준비물 안내, 신청 경로가 모두 있는지 하나씩 확인하세요. 상호작용을 해야 나타나는 화면 뒤에 모든 강좌 정보를 넣기 전에 점검 도구가 어떤 버전을 가져오는지 먼저 확인합니다. 최초 응답에 외형만 있다면 개발자에게 렌더링 방식을 검토하고 서버 측 렌더링이나 미리 생성한 콘텐츠가 적합한지 평가해 달라고 요청하세요.

홈페이지에서 강좌 분류, 개별 강좌, 관련 글로 이어지는 경로를 직접 따라가 중요한 페이지에 크롤러가 따라갈 수 있는 링크 입구가 있는지 확인합니다. 메뉴 단계 수만 세지 말고 고립된 페이지, 잘못된 목적지, 과도한 리디렉션을 기록하세요. 완료 여부를 판단할 때는 크롤러가 URL을 찾을 수 있는지와 함께 독자가 다음에 어디로 갈지 이해할 수 있는지도 살펴야 합니다.

네 번째 단계: 사용 경험과 검색 노출 개선 일정 정하기

기본 기능이 작동하면 모바일 로딩, 상호작용, 레이아웃 안정성을 살펴보세요. Core Web Vitals의 현재 지표인 LCP, INP, CLS는 각각 이러한 측면을 다룹니다. 강좌 이미지가 신청 버튼을 밀어내거나 클릭해도 반응하지 않는 것 같은 실제 문제를 먼저 찾고, 도구의 데이터로 원인을 파악하세요. 한 번 측정한 속도 점수가 사용자 경험을 대신하지는 않습니다.

사이트에서 구조화 데이터를 사용한다면 마크업이 페이지에 보이는 내용 및 해당 유형의 공식 규칙과 맞는지 확인하세요. 특별한 검색 표시를 얻으려고 가짜 평점이나 페이지에 없는 정보를 추가해서는 안 됩니다. 리치 결과 테스트는 기술 문제를 찾는 데 도움이 되지만 통과해도 그 검색 표시가 반드시 나타나는 것은 아닙니다.

개선을 강좌 이미지 공간 확보, 공통 데이터 필드 하나 수정, 지나치게 큰 리소스 줄이기처럼 범위가 작은 작업으로 나누세요. 각 작업의 변경 전후 예시를 남기고 신청과 읽기가 여전히 정상인지 확인합니다. 그러면 비용을 계획하기 쉽고 예상 밖의 결과가 나왔을 때 어느 변경이 원인인지 추적하는 데도 도움이 됩니다.

완료할 수 있는 작업으로 이어지는 감사 보고서 작성하기

문제는 중요한 콘텐츠의 열람을 막는지, 일부 진입 경로나 정보에 영향을 주는지, 품질과 유지관리의 개선 사항인지에 따라 우선순위를 매길 수 있습니다. 영향받는 페이지 수와 수정 위험은 따로 표시하세요. 이는 운영을 위한 분류이지 Google이 발표한 점수가 아닙니다. 심각성이 같은 두 문제라면 핵심 서비스에 영향을 주고 원인이 분명한 것부터 처리하세요.

각 작업 항목에는 재현 단계, 기대 결과, 현재 결과, 영향받는 URL, 완료 기준이 필요합니다. 예를 들어 '로그아웃한 방문자가 강좌 페이지에서 올바른 시간을 보고, 성공 응답을 받으며, 의도하지 않은 noindex가 없다'는 'SEO 개선'보다 훨씬 확인하기 쉽습니다. 공통 템플릿을 수정했다면 이전에 정상적이던 다른 페이지도 표본으로 다시 확인하세요.

보고서 마지막에는 완료한 수정, 아직 진행 중인 색인 갱신, 계속 관찰할 성과를 따로 나열하세요. 사이트 설정이 검사에 통과하면 기술 작업은 완료할 수 있습니다. 검색 데이터가 아직 갱신되지 않았다면 추적 날짜를 남기고 기다리는 기간을 이미 순위 상승을 얻은 것처럼 설명하지 마세요. 다음 개편에서는 같은 대표 페이지를 완료 기준선으로 다시 사용할 수 있습니다.

1. 공개 범위와 페이지 유형별 대표 URL을 정하고 개편에서 바뀐 내용을 기록한다.
2. 접근, 색인, 렌더링, 링크, 사용 경험 순서로 근거를 수집한다.
3. 각 문제의 영향, 담당자, 재현 가능한 완료 기준을 적는다.
4. 수정 후 영향받은 템플릿을 다시 점검하고 색인과 검색 데이터는 따로 추적한다.

크롤링 효율과 사이트 로그 자세히 살펴보기

사이트를 개편하기 전에 백업하기

• 튜토리얼
• 앱·소프트웨어
• 마케팅·SEO
• SEO