테크니컬 SEO 점검 체크리스트 — 순위 하락 진단에서 실제로 보는 12가지

테크니컬 SEO는 왜 먼저인가?

순위 하락 진단을 하면 원인이 "콘텐츠가 나빠서"인 경우보다 "검색엔진이 사이트를 제대로 못 읽어서" 인 경우가 훨씬 많습니다. 이 글은 진단 때 실제로 보는 항목을 순서대로 정리한 체크리스트입니다. 각 항목에 구글 공식 문서 기준과 확인 방법을 붙였습니다.

순서가 중요합니다. 1~4번이 막혀 있으면 나머지는 확인해도 소용없습니다.

1~3. 크롤링과 색인: 검색엔진이 들어올 수 있나?

robots.txt는 사이트 루트의 텍스트 파일로, 크롤러에게 어디를 읽지 말라고 알리는 용도입니다. Disallow: /가 있으면 전체 차단입니다. 개발 중 막아뒀다가 오픈 후 안 푸는 사례가 정말 많습니다. 구글 문서는 robots.txt가 색인 제외 수단이 아니라고도 강조합니다 — 이미 색인된 페이지를 빼려면 noindex 메타 태그를 써야 하고, 그 페이지는 robots.txt로 막으면 안 됩니다(막으면 구글이 noindex를 읽지 못합니다).

사이트맵은 사이트의 페이지 목록입니다. 구글 문서 기준으로 새 사이트, 페이지가 많은 사이트, 내부 링크가 약한 사이트에 특히 필요합니다. lastmod는 실제 수정일이어야 합니다. 모든 페이지가 빌드 시각으로 같은 날짜면 정보가 없는 것과 같고, 지난주 구글이 확인했듯 사이트맵 주소에 매일 바뀌는 파라미터를 붙이는 편법은 역효과입니다.

색인 상태는 서치콘솔 → 페이지 보고서에서 봅니다. "색인 생성되지 않음" 사유별 개수가 진단의 출발점입니다.

4~6. URL 정리: 같은 페이지가 하나의 주소인가?

canonical은 "이 내용의 대표 주소"를 알리는 태그입니다. 흔한 오류는 사이트 제작 도구가 모든 페이지의 canonical을 홈 주소로 통일해 버리는 것, 또는 http/https나 www 유무가 다른 주소를 가리키는 것입니다. 원칙은 각 페이지의 canonical이 자기 자신의 최종 주소를 가리키는 것입니다.

주소 통일은 네 가지 조합을 확인합니다. http://, https://, www. 유무, 끝 슬래시 유무. 이 중 하나만 정식이고 나머지는 전부 그 주소로 301(영구) 리다이렉트되어야 합니다. 터미널에서 확인하는 방법:

curl -sI http://example.com | findstr /i "HTTP Location"
curl -sI https://www.example.com | findstr /i "HTTP Location"

리다이렉트는 구글 문서상 영구 이동은 301/308, 임시는 302/307을 씁니다. 진단에서 자주 보는 문제는 세 가지입니다. A→B→C처럼 여러 번 거치는 체인(각 단계마다 신호가 약해지고 느려짐), 서로를 가리키는 루프(이번 달 저희 사이트에서도 대시보드 설정과 코드 설정이 겹쳐 잠깐 발생했습니다), 그리고 옛 URL이 리다이렉트 없이 404로 남은 경우입니다.

7~8. 속도와 모바일: 빠르고 제대로 보이나?

구글은 Core Web Vitals를 페이지 경험 신호로 검색 순위에 반영한다고 밝혔습니다. 세 지표와 "양호" 기준치는 web.dev 문서 기준으로 다음과 같습니다.

확인은 PageSpeed Insights(실사용자 데이터 + 실험실 데이터)와 서치콘솔의 Core Web Vitals 보고서로 합니다. 점수 100이 목표가 아니라 세 지표가 기준치 안에 들어오는 것이 목표입니다. 현장에서 LCP를 늦추는 원인은 대부분 셋입니다 — 압축 안 된 큰 이미지, 웹폰트 전체 파일 로딩, 화면을 막는 자바스크립트. 저희 사이트도 한글 웹폰트 2MB가 LCP를 12초로 만들었다가, 사이트에 쓰는 글자만 담은 124KB 서브셋으로 바꿔 해결했습니다.

모바일은 구글이 모바일 버전을 기준으로 색인하므로(모바일 우선 색인), 데스크톱에만 있고 모바일에서 숨긴 내용은 없는 것으로 취급됩니다. 실제 폰으로 열어 본문·이미지·링크가 데스크톱과 같은지, 팝업이 내용을 가리지 않는지 확인합니다.

9~10. 구조화 데이터와 렌더링: 기계가 이해할 수 있나?

구조화 데이터(JSON-LD)는 "이 페이지는 회사 소개다, 이 상품의 가격은 얼마다, 이건 FAQ다"를 기계가 읽는 형식으로 적는 것입니다. 구글은 이를 리치 결과에 쓰고, AI 검색도 사이트 이해에 참고합니다. 기본으로 넣는 것은 Organization(회사), WebSite, BreadcrumbList이고 페이지 성격에 따라 Service·Product·FAQPage·Article·LocalBusiness를 더합니다. 검증은 구글 리치 결과 테스트로 합니다. 페이지에 없는 내용을 구조화 데이터에만 넣는 것은 구글 정책 위반이니, 화면에 보이는 것과 일치시켜야 합니다.

자바스크립트 렌더링은 요즘 사이트에서 가장 자주 놓치는 항목입니다. 페이지를 처음 받았을 때 HTML에 본문이 없고 스크립트 실행 후에 채워지는 구조라면, 구글은 렌더링을 하긴 하지만 시간이 더 걸리고, 다른 검색엔진과 AI 크롤러 대부분은 실행하지 않습니다. 확인은 서치콘솔 URL 검사 → "크롤링된 페이지 보기"에서 렌더링된 HTML에 본문이 있는지 보는 것입니다. 해결은 서버에서 HTML을 완성해 보내는 것(SSR·정적 생성)입니다. 저희가 제작하는 사이트를 전부 정적 생성으로 만드는 이유입니다.

11. 서버 응답과 오류

서치콘솔 → 설정 → 크롤링 통계에서 응답 코드 분포와 평균 응답 시간을 봅니다. 5xx 오류가 반복되면 구글은 크롤링 빈도를 줄입니다. 응답 시간이 수 초 단위라면 호스팅 문제입니다. 저가 공유 호스팅에서 트래픽이 늘며 느려지는 경우가 국내에서 흔합니다.

12. 사이트 이전 이력 — 급락의 숨은 원인

순위가 특정 시점에 급락했다면 그 시점에 무엇이 바뀌었는지 묻습니다. 도메인 변경, 리뉴얼로 URL 구조 변경, https 전환, CMS 교체. 구글의 사이트 이전 문서가 요구하는 것은 옛 URL → 새 URL 1:1 301 리다이렉트, 서치콘솔 주소 변경 도구 사용, 사이트맵 갱신, 외부 링크·프로필 갱신입니다. 이 중 하나라도 빠지면 회복이 몇 달씩 걸리고, 이번 주 소식처럼 아예 회복되지 않는 사례도 있습니다. 리뉴얼 전에 옛 URL 전체 목록을 뽑아 두는 것이 가장 싼 보험입니다.

우선순위는 어떻게 정하나?

12개를 전부 고치자고 하지 않습니다. 기준은 효과 대비 비용입니다.

1. 0을 1로 만드는 것 — 크롤링 차단, noindex 오설정, canonical 전체 오류, 리다이렉트 루프. 고치는 순간 검색에 나오기 시작합니다.
2. 새는 것을 막는 것 — 주소 미통일, 리다이렉트 체인, 404로 남은 옛 URL, 5xx.
3. 더 좋게 만드는 것 — 속도 기준치 진입, 구조화 데이터 확장, 렌더링 방식 전환.

1번이 있으면 3번은 나중입니다. 진단 리포트는 이 순서로 씁니다.

지금 할 일

• 내사이트/robots.txt에 Disallow: /가 없는지, Sitemap: 줄이 있는지 확인
• 서치콘솔 페이지 보고서에서 "색인 생성되지 않음" 사유 상위 3개 기록
• 대표 페이지 3개의 canonical이 자기 자신의 https 주소를 가리키는지 소스에서 확인
• http·www 조합 4가지가 모두 정식 주소로 한 번에 301 되는지 확인
• PageSpeed Insights 모바일에서 LCP·INP·CLS가 기준치 안인지 확인
• URL 검사 → 렌더링된 HTML에 본문이 들어 있는지 확인
• 최근 1년 안에 URL·도메인이 바뀐 적이 있다면 옛 URL 리다이렉트 상태 확인

이 일곱 가지가 무료 진단 리포트의 1차 항목이기도 합니다. 직접 확인이 어렵거나 결과 해석이 필요하면 사이트 주소만 보내주세요. 어디가 막혔는지 먼저 알려드립니다.