기술적 SEO 체크리스트 2026, 순위 전에 이것부터

결론부터 말하면 이렇다. 좋은 콘텐츠를 아무리 많이 쌓아도, 구글이 그 페이지를 크롤링하고 색인할 수 없으면 순위 경쟁 자체가 시작되지 않는다. 콘텐츠 품질과 백링크는 그다음 단계의 이야기다. 기술적 SEO는 화려하지 않지만, 순서를 건너뛰면 나머지 노력이 통째로 새는 구멍이 된다.

문제는 항목이 너무 많고 여기저기 흩어져 있다는 점이다. 크롤링·색인, robots.txt, 사이트맵, 캐노니컬, 리다이렉트, 코어 웹 바이탈, 구조화 데이터, 모바일 최적화, HTTPS, URL 구조까지 — 어디부터 손대야 할지 감이 안 온다면 이 글이 그 순서를 잡아 준다. 각 항목의 세부 내용은 이미 개별 심층 가이드로 다뤘으니, 이 글은 "무엇을 어떤 순서로 봐야 하는가" 라는 지도 역할에 집중한다.

이 글의 핵심만 먼저 추리면 이렇다.

• 점검 순서는 크롤링·색인 → robots.txt·사이트맵 → 중복/캐노니컬 → 리다이렉트 → 속도 → 구조화 데이터 → 모바일·보안 → URL 순이 합리적이다.
• 크롤링 통계 보고서(서치 콘솔 설정 > 크롤링 통계)에서 응답 코드와 호스트 상태부터 본다.
• 2026년 코어 웹 바이탈 기준은 LCP 2.5초, INP 200밀리초, CLS 0.1 이하가 "양호"다.
• 구글은 2026년 5월 7일부로 FAQ 리치 결과 자체를 완전히 폐지했다 — 구조화 데이터 우선순위가 바뀌었다.
• 업종·규모와 무관하게 같은 순서가 적용되지만, 무엇을 먼저 고칠지는 사이트 상태에 따라 달라진다.

왜 콘텐츠보다 기술적 SEO를 먼저 봐야 할까

구글의 검색 과정은 크롤링 → 색인 → 랭킹 세 단계로 진행된다. 앞의 두 단계가 막히면 세 번째 단계인 랭킹 경쟁 자체에 참여하지 못한다. 아무리 잘 쓴 글도 색인이 안 되면 검색 결과에 존재하지 않는 것과 같다.

실무에서는 순서가 자주 뒤바뀐다. 콘텐츠 발행량을 늘리는 데 집중하다가, 정작 새 페이지들이 색인조차 되지 않고 있었다는 사실을 몇 달 뒤에야 발견하는 경우가 흔하다. 이런 사이트는 대개 방문자 수 그래프가 몇 달째 평평하고, 신규 글을 아무리 늘려도 순위와 트래픽이 함께 늘지 않는다는 공통점을 보인다. 기술적 SEO 점검은 콘텐츠 제작보다 항상 먼저, 그리고 정기적으로 반복해야 하는 작업이다.

원인을 뒤늦게 찾다 보면 대개 한두 가지로 좁혀진다. 리뉴얼 과정에서 robots.txt 설정이 통째로 바뀌었거나, 플랫폼을 이전하면서 예전 URL의 리다이렉트를 빠뜨렸거나, 캐노니컬 태그가 엉뚱한 URL을 가리키고 있는 식이다. 이런 문제는 콘텐츠 자체와 무관하기 때문에, 글을 아무리 다시 써도 해결되지 않는다. 오히려 원인을 모른 채 콘텐츠만 늘리면 문제 있는 페이지 수만 함께 늘어나는 셈이라 상황이 더 나빠진다.

새 페이지를 발행할 때마다 "잘 썼는가"보다 먼저 "구글이 찾아올 수 있는가"를 물어야 한다.

이 체크리스트는 사업자가 스스로 점검할 수 있도록 항목별로 왜 중요한지, 어디서 확인하는지, 실제로 자주 나오는 실수는 무엇인지 순서대로 정리했다.

1단계: 크롤링과 색인 상태부터 확인했나요

가장 먼저 볼 것은 페이지가 크롤링되고 있는지, 그리고 크롤링된 페이지가 색인까지 됐는지 여부다. 이 둘은 다른 단계다. 크롤링됐다고 반드시 색인되는 것은 아니며, 콘텐츠 품질이 낮거나 중복으로 판단되면 크롤링은 됐어도 색인에서 제외될 수 있다.

서치 콘솔의 설정 > 크롤링 통계로 들어가면 확인할 수 있는 항목들이 있다. 성공 여부와 관계없이 사이트에서 발생한 총 크롤링 요청 수, 응답 코드별 분류(200·301·302·404·5XX), HTML·이미지·JavaScript·CSS 같은 파일 형식별 분류, 그리고 호스트 상태(초록·노랑·빨강)다. 호스트 상태가 빨간색이면 robots.txt 접근 문제나 DNS·서버 연결 문제가 지난주에 있었다는 뜻이니 다른 무엇보다 먼저 확인해야 한다.

참고로 구글은 기본적으로 스마트폰용 Googlebot으로 크롤링하며, 별도의 데스크톱 전용 Googlebot도 존재한다. 두 봇의 크롤링 비율은 크롤링 통계 보고서의 "Googlebot 유형별" 항목에서 확인할 수 있는데, 특정 유형의 요청이 유독 실패율이 높다면 해당 화면(모바일 또는 데스크톱)에서만 발생하는 오류일 가능성이 크다.

개별 URL 단위로는 URL 검사 도구에서 "색인 생성됨" 여부를 바로 확인할 수 있다. 신규 사이트라면 초반에 크롤 예산(구글이 한 사이트에 할애하는 크롤링 자원)이 보수적으로 배정되는 경향이 있다는 점도 알아 두면 좋다. 구글 색인의 기본 작동 원리를 먼저 이해해 두면 이후 항목을 판단하기 쉬워진다.

색인 커버리지 보고서에서는 페이지가 몇 가지 상태로 분류된다. "제출됨, 색인이 생성됨"이 정상이고, "검색됨, 현재 색인이 생성되지 않음"은 구글이 발견은 했지만 아직 처리하지 않았다는 뜻이며, "중복 콘텐츠, 사용자가 표준으로 선정한 URL 없음"은 캐노니컬을 지정하지 않아 생기는 문제다. 어떤 상태인지에 따라 다음에 손볼 항목이 달라지므로, 무작정 "색인이 안 됐다"고만 판단하지 말고 정확한 상태 문구를 먼저 확인해야 한다.

좋은 예: 새 글을 발행하면 서치 콘솔 커버리지 보고서에서 1–2주 안에 "정상" 상태로 넘어간다. 나쁜 예: 발행한 지 한 달이 지나도 "검색됨(색인 생성 안 됨)" 상태로 남아 있는데, 원인을 찾지 않고 새 글만 계속 늘린다.

2단계: robots.txt와 사이트맵, 서로 충돌하지 않나요

robots.txt는 크롤링을 차단하는 파일이고, 사이트맵은 크롤링을 권유하는 파일이다. 이 둘이 모순되면 구글은 혼란스러워한다. 대표적인 실수는 robots.txt에서 특정 경로를 차단해 놓고, 그 경로의 URL을 사이트맵에는 여전히 넣어 두는 경우다.

# 나쁜 예 — robots.txt는 막고, 사이트맵엔 그대로 노출
Disallow: /search/

사이트맵(sitemap.xml)에는 /search/?q= 로 시작하는 내부 검색 결과 URL이 수백 개 남아 있는 상태라면, 구글 입장에서는 "크롤링하지 말라"는 신호와 "여기 봐 달라"는 신호가 동시에 오는 셈이다. 좋은 예는 robots.txt로 막은 경로는 사이트맵 생성 로직에서도 함께 제외하는 것이다.

robots.txt를 아직 정확히 모른다면 robots.txt란 무엇인지 정리한 글을 먼저 읽는 것을 권한다. 사이트맵의 기본 개념과 lastmod 필드 활용법은 사이트맵 가이드에서 다룬다.

점검할 것은 세 가지로 정리된다. robots.txt가 중요한 페이지를 실수로 막고 있지 않은가, 사이트맵에 노출을 원하지 않는 URL(관리자 페이지, 검색 결과 페이지, 장바구니 등)이 섞여 있지 않은가, 사이트맵이 서치 콘솔에 정상 제출되어 "성공" 상태인가.

페이지 수가 많은 사이트라면 사이트맵을 하나로 뭉치기보다, 카테고리·상품·블로그처럼 성격별로 나눈 뒤 이를 묶는 사이트맵 색인 파일을 쓰는 편이 관리하기 쉽다. 또한 사이트맵의 lastmod 값은 실제 콘텐츠가 바뀐 날짜와 정확히 일치해야 한다. 아무 페이지나 매일 새 날짜로 갱신해 두면, 구글이 정말 바뀐 페이지와 안 바뀐 페이지를 구분하지 못해 오히려 신뢰도가 떨어질 수 있다.

robots.txt로 막힌 페이지는 사이트맵에서도 빼는 것이 원칙이다. 두 파일의 메시지가 같아야 구글이 헷갈리지 않는다.

3단계: 캐노니컬과 중복 콘텐츠, 왜 순위를 깎을까

같은 내용이 여러 URL로 존재하면(대소문자, 파라미터, www 유무, http/https 등) 구글은 어느 URL을 대표로 삼아야 할지 스스로 판단해야 한다. 사이트 운영자가 명시적으로 정본을 지정하지 않으면, 구글이 엉뚱한 URL을 대표로 고르거나 순위 신호가 여러 URL로 분산될 수 있다.

예를 들어 example.com/product, www.example.com/product, example.com/product/(끝에 슬래시 포함) 세 가지가 모두 같은 상품 페이지로 열린다면, 이는 사람 눈에는 같은 페이지지만 구글에는 세 개의 서로 다른 URL이다. 정규 URL(canonical) 태그는 이 문제를 해결하는 가장 기본적인 방법이다. 모든 페이지는 원칙적으로 자기 자신을 가리키는 자기참조 캐노니컬을 가져야 하며, 중복 버전이 있다면 대표 URL 하나를 명시해야 한다. 자세한 원리는 캐노니컬 태그와 반영 시간을 다룬 글에서 확인할 수 있다.

캐노니컬 확인은 특별한 도구 없이도 가능하다. 페이지 소스 보기(또는 개발자 도구)에서 <link rel="canonical"> 태그를 찾아, 그 안의 URL이 지금 보고 있는 페이지 자신과 일치하는지만 보면 된다. 여러 페이지가 모두 같은 대표 URL 하나만 가리키고 있다면 잘못 설정된 것이다.

목록·필터·정렬 옵션이 있는 페이지(가격순, 인기순, 페이지네이션 등)도 중복 콘텐츠의 흔한 원인이다. 상품 목록 자체는 같고 정렬 순서만 다른 URL이 계속 생성된다면, 이 역시 대표 URL 하나로 캐노니컬을 모아 주는 것이 안전하다.

주의할 점이 하나 있다. 캐노니컬을 수정해도 구글이 이를 반영하는 데는 시간이 걸린다. 당장 순위가 안 바뀐다고 설정이 잘못됐다고 오해하지 말아야 한다. 최소 2–3주는 기다려 본 뒤 URL 검사 도구로 재확인하는 것이 순서다.

4단계: 리다이렉트, 체인만 없으면 되는 걸까

URL을 옮기거나 통합할 때는 301 리다이렉트로 이전 URL의 신호를 새 URL로 넘겨준다. 반면 일시적으로만 다른 주소를 보여주고 싶다면 302를 쓴다. 둘을 혼동해 영구 이전인데도 302를 계속 쓰면, 구글이 "언젠가 원래 URL로 돌아갈 것"으로 판단해 신호 이전이 더디게 일어날 수 있다.

문제는 리다이렉트 체인이다. A에서 B로, B에서 다시 C로 이어지는 식으로 단계가 늘어날수록 페이지 로딩이 느려지고, 일부 신호가 손실될 위험도 커진다.

나쁜 예: 몇 년 전 URL 구조를 개편하면서 예전 URL을 새 URL로, 그 새 URL을 다시 최신 URL로 바꾸는 과정에서 리다이렉트가 세 단계, 네 단계로 쌓인 채 방치된 경우다. 좋은 예: 최초 URL에서 최종 URL로 한 번에 연결되도록, 개편이 있을 때마다 중간 리다이렉트를 함께 정리하는 경우다.

메타 리프레시(HTML 문서 안에 몇 초 뒤 다른 페이지로 이동하라고 적어 두는 방식)나 자바스크립트로만 처리하는 이동도 실제로 동작은 하지만, 검색엔진 입장에서는 서버가 보내는 301 리다이렉트만큼 명확한 신호가 아니다. 이전이 확정된 URL이라면 서버 단(호스팅 관리자 도구, .htaccess, 혹은 사용 중인 플랫폼의 리다이렉트 설정 메뉴)에서 301로 직접 처리하는 것이 원칙이다.

5단계: 코어 웹 바이탈, 2026년 기준은 무엇인가

페이지 속도는 사용자 경험 지표인 동시에 순위 신호다. 구글이 쓰는 코어 웹 바이탈은 세 가지 지표로 구성된다.

지표	양호	개선 필요	나쁨	주요 원인
LCP(최대 콘텐츠풀 페인트)	2.5초 이하	2.5–4.0초	4.0초 초과	용량 큰 이미지, 느린 서버 응답
INP(다음 페인트까지 상호작용)	200밀리초 이하	200–500밀리초	500밀리초 초과	무거운 자바스크립트, 과도한 이벤트 처리
CLS(누적 레이아웃 이동)	0.1 이하	0.1–0.25	0.25 초과	크기 지정 안 된 이미지·광고, 늦게 로드되는 폰트

INP는 2024년 3월 기존 FID(최초 입력 지연) 지표를 대체한 이후 지금까지 그대로 쓰이고 있으며, 2026년에도 새로운 지표가 추가되거나 임계값이 바뀌지는 않았다. 다만 업계 조사에서는 여전히 상당수 사이트가 INP 기준을 넘기지 못한다고 보고되는 만큼, 세 지표 중 가장 자주 놓치는 것이 INP라는 점을 기억해야 한다.

속도에 직접 영향을 주는 항목은 이미지와 폰트다. 이미지는 원본 파일을 그대로 올리지 말고 웹에 맞는 포맷과 크기로 압축해야 하며, 폰트는 화면이 늦게 뜨더라도 텍스트만은 먼저 보이도록 로딩 방식을 조정하는 것이 핵심이다.

측정은 두 가지를 함께 봐야 한다. 실험실 환경에서 페이지를 인위적으로 분석하는 진단 도구(랩 데이터)와, 실제 방문자의 기기·회선에서 수집된 서치 콘솔의 환경 보고서(필드 데이터)다. 진단 도구 점수가 좋아도 실제 방문자 데이터가 나쁘게 나오는 경우가 있는데, 이때는 방문자 다수가 쓰는 환경(예: 저사양 모바일, 느린 회선)을 기준으로 우선순위를 잡아야 한다.

코어 웹 바이탈은 "합격/불합격"이 아니라 "얼마나 많은 방문자가 좋은 경험을 했는가"의 비율이다. 일부 느린 기기·회선 사용자 때문에 항상 100%가 나오기는 어렵다.

우선순위를 정할 때는 세 지표 중 가장 나쁜 등급을 받은 지표부터 손보는 것이 효율적이다. 세 지표를 동시에 다 고치려 하면 어느 것도 끝내지 못한 채 시간만 흘러가는 경우가 많다. 예를 들어 LCP는 이미 양호한데 CLS만 나쁘다면, 이미지·광고 영역에 가로세로 크기를 미리 지정해 주는 작업 하나만으로도 눈에 띄게 개선되는 경우가 흔하다.

6단계: 구조화 데이터, 아직도 다 넣어야 할까

구조화 데이터(JSON-LD)는 검색엔진이 페이지 내용을 정확히 이해하도록 돕는 마크업이다. 여기서 2026년에 꼭 알아야 할 변화가 하나 있다. 구글은 2026년 5월 7일부터 FAQ 리치 결과 노출을 완전히 중단했다. 그전에도 2023년 8월부터 일부 정부·의료 기관 사이트로만 노출이 제한돼 있었는데, 이번에는 그 제한적인 노출마저 완전히 사라졌다.

그렇다고 FAQPage 마크업을 당장 지울 필요는 없다. 리치 결과 노출만이 목적이었다면 제거해도 무방하지만, 페이지에 실제로 도움이 되는 FAQ 콘텐츠 자체는 그대로 남겨 두는 것이 맞다. AI 검색·챗봇이 답변을 인용할 때는 질문과 답이 명확히 짝지어진 구조 자체가 여전히 유용하기 때문이다. 무리해서 다른 스키마 유형으로 바꿔치기할 이유도 없다.

이 밖에도 구글은 실습 문제, 영양 정보, 근처 매장 혜택처럼 사용 빈도가 낮은 일부 구조화 데이터 유형의 지원을 2026년 1월부터 순차적으로 정리했다. 반면 Article(BlogPosting), BreadcrumbList, LocalBusiness, Product, Review처럼 실무에서 자주 쓰이는 핵심 유형은 여전히 유효하다. 2026년 기준으로 지원이 중단된 유형 전체 목록은 구조화 데이터 지원 중단 총정리에서 확인할 수 있다.

좋은 예: 블로그 글에는 Article, 지역 매장 페이지에는 LocalBusiness처럼 페이지 성격에 맞는 핵심 스키마만 정확히 넣는다. 나쁜 예: 리치 결과 노출을 기대하며 이미 폐지된 FAQPage 스키마 유지·관리에 계속 시간을 쓴다.

구조화 데이터를 새로 넣거나 수정했다면, 문법 오류 없이 인식되는지 검증 도구로 확인하는 절차를 빼먹지 말아야 한다. 스키마 자체는 문제없이 작성했더라도 페이지 안에 중복으로 여러 번 삽입되거나, 실제 화면에 보이지 않는 정보를 스키마에만 적어 두는 경우(예: 페이지에 없는 평점을 스키마에만 표시)는 정책 위반으로 간주될 수 있으니 화면에 보이는 내용과 스키마 내용을 반드시 일치시켜야 한다.

7단계: 모바일 최적화와 HTTPS, 이제는 기본값인가요

구글은 2020년대 초반부터 모바일 우선 색인을 전체 사이트로 확대해 왔고, 2026년 현재는 사실상 거의 모든 사이트가 모바일 버전 콘텐츠를 기준으로 색인되고 있다. 즉 PC 화면에만 존재하고 모바일 화면에는 빠진 콘텐츠가 있다면, 그 콘텐츠는 색인에도 반영되지 않을 가능성이 크다.

점검 포인트는 단순하다. 모바일에서 봤을 때 PC와 동일한 본문·이미지·링크가 모두 나오는지, 글자 크기와 버튼 간격이 터치에 불편하지 않은지, 팝업이나 배너가 본문을 가리지 않는지다. 특히 상담 신청 폼이나 전화 버튼처럼 전환에 직결되는 요소가 모바일에서 눌리기 어렵게 배치돼 있지 않은지도 함께 봐야 한다.

HTTPS는 이제 논의 대상이 아니라 최소 기준이다. SSL 인증서 없이 운영되는 사이트는 브라우저에서 "안전하지 않음" 경고를 받고, 검색 순위에서도 불리하다. 인증서는 있는데 일부 이미지나 스크립트만 http://로 불러오는 혼합 콘텐츠 문제도 흔한 실수 중 하나이니 함께 점검해야 한다.

인증서를 발급했다고 끝이 아니다. 자동 갱신이 설정돼 있지 않으면 인증서 만료일에 사이트 전체가 갑자기 경고 화면으로 뒤덮이는 사고로 이어질 수 있다. 만료일을 사람이 수동으로 챙기기보다, 갱신을 자동화해 두거나 최소한 만료 한 달 전 알림을 받도록 설정해 두는 것이 안전하다.

8단계: URL 구조, 지금이라도 고쳐야 할까요

URL은 사람과 검색엔진 모두에게 주소이자 첫인상이다. 의미 없는 숫자나 파라미터로만 이뤄진 URL보다, 짧고 내용이 읽히는 URL이 클릭률과 관리 편의성 양쪽에서 유리하다.

나쁜 예: example.com/?p=1029&cat=3 좋은 예: example.com/blog/technical-seo-checklist

이미 순위가 어느 정도 잡힌 페이지의 URL을 지금 바꾸는 것은 신중해야 한다. URL을 바꾸면 반드시 이전 URL에서 새 URL로 301 리다이렉트를 걸어야 하고, 일시적인 순위 변동을 감수해야 한다. 신규 페이지라면 처음부터 규칙을 정해 짧고 하이픈으로 단어를 구분한 URL을 쓰는 것이 이후 골치 아픈 일을 만들지 않는 길이다. 구체적인 슬러그 설계 기준은 URL 구조 설계 가이드에서 다룬다.

고친 뒤 순위에 반영되기까지 얼마나 걸리나요

항목마다 반영 속도가 다르다는 점을 모르면, 고치고 나서 하루 이틀 만에 "효과가 없다"고 성급하게 판단하기 쉽다.

robots.txt 수정은 구글이 다음 크롤링 때 바로 읽어 가지만, 그 결과로 새 페이지가 색인되거나 막혔던 페이지가 빠지는 데는 크롤링 빈도에 따라 며칠에서 몇 주가 걸릴 수 있다. 사이트맵 재제출도 비슷해서, 제출 자체는 즉시 반영되지만 실제 크롤링·색인은 순차적으로 진행된다.

캐노니컬 변경은 앞서 언급했듯 구글이 재평가하는 데 통상 2–3주가 걸린다. 리다이렉트는 설정 직후부터 새 URL로 신호가 이전되기 시작하지만, 예전 URL에 쌓여 있던 순위 신호가 완전히 옮겨 오는 데는 몇 주가 걸릴 수 있다. 코어 웹 바이탈은 서치 콘솔 환경 보고서 자체가 최근 28일치 실제 사용자 데이터를 기준으로 집계되므로, 개선 효과가 보고서 수치에 온전히 반영되기까지 최소 한 달가량 걸린다고 보는 것이 현실적이다.

기술적 SEO 개선의 효과는 대부분 "즉시"가 아니라 "몇 주 뒤"에 나타난다. 조급하게 되돌리기보다, 정해 둔 기간만큼은 기다렸다가 재확인하는 것이 순서다.

업종별로 특히 자주 놓치는 실수는 무엇인가

체크리스트 항목은 같아도, 업종에 따라 유독 자주 걸리는 지점은 다르다.

쇼핑몰은 상품 옵션·정렬·필터 조합마다 URL이 새로 생기면서 중복 콘텐츠가 순식간에 수천 개로 불어나는 경우가 많다. 캐노니컬을 대표 상품 URL로 정확히 고정하지 않으면 색인 낭비로 이어진다.

지역 기반 서비스업(병원, 학원, 식당 등)은 모바일 최적화와 페이지 속도에 특히 취약하다. 예약 폼이나 지도가 무겁게 로드되면서 LCP·INP가 함께 나빠지는 경우가 흔하다.

정보성 블로그형 사이트는 태그·카테고리 페이지가 늘어나면서 비슷한 글 목록이 여러 URL에 중복 노출되는 문제가 잦다. 이 경우 캐노니컬과 함께 불필요한 태그 페이지의 색인 여부 자체를 재검토하는 것이 순서다.

소규모 사업자 홈페이지(1인 기업, 프리랜서, 소규모 매장)는 위 세 유형에 비해 페이지 수는 적지만, 오히려 기본기가 아예 빠져 있는 경우가 많다. 저렴한 템플릿을 그대로 쓰면서 캐노니컬 태그 자체가 없거나, robots.txt 파일이 처음부터 존재하지 않아 기본값에만 의존하는 식이다. 페이지 수가 적을수록 한 번 점검으로 대부분의 문제를 해결할 수 있으므로, 오히려 손이 덜 가는 편에 속한다.

업종이 다르더라도 공통으로 확인할 것은 하나다. 문제가 페이지 몇 개에 국한된 것인지, 사이트 구조 전체에 걸친 것인지를 먼저 구분하는 일이다. 구조 전체의 문제라면 템플릿이나 플랫폼 설정을 고쳐야 하고, 개별 페이지의 문제라면 해당 페이지만 수정하면 된다. 이 구분 없이 페이지 하나씩 손보다 보면 같은 문제를 계속 반복해서 고치게 된다.

어떤 순서로, 얼마나 자주 점검해야 할까

항목을 다 알아도 순서가 없으면 결국 손이 가는 것부터 하게 된다. 아래 순서를 권한다.

1. 크롤링·색인 상태(호스트 상태, 커버리지) — 문제가 있으면 다른 작업은 뒤로 미룬다. 여기가 막혀 있으면 이후 어떤 항목을 고쳐도 구글이 확인할 방법이 없다.
2. robots.txt·사이트맵 정합성 — 차단과 노출 신호가 일치하는지. 두 파일은 항상 세트로 함께 점검한다.
3. 캐노니컬·중복 콘텐츠 — 순위 신호가 한 URL로 모이는지. 신호가 분산되면 어느 URL도 제대로 순위를 받지 못한다.
4. 리다이렉트 체인 정리 — 신호 손실과 속도 저하를 막는다. 개편이 잦은 사이트일수록 누적되기 쉬운 항목이다.
5. 코어 웹 바이탈 — 사용자 경험과 직결되는 속도 지표. 개선 효과가 보고서에 반영되기까지 시간이 걸린다는 점을 감안한다.
6. 구조화 데이터 — 폐지된 유형 정리, 핵심 유형 점검. 화면에 보이는 내용과 항상 일치시킨다.
7. 모바일·HTTPS — 기본기가 무너지지 않았는지 재확인. 인증서 자동 갱신 여부도 함께 본다.
8. URL 구조 — 신규 페이지부터 규칙을 지킨다. 이미 순위가 있는 URL은 꼭 필요한 경우가 아니면 그대로 둔다.

한 번에 다 끝내려 하지 말아야 한다. 위 순서대로 한 달에 한 번씩만 훑어도, 문제를 몇 달씩 방치하는 것보다 훨씬 낫다.

이미 홈페이지를 새로 만드는 단계라면, 제작 이전 단계에서 챙길 항목은 제작 전 SEO 체크리스트에서 별도로 다루고 있으니 이 글과 함께 보면 좋다. 이 글은 이미 운영 중인 사이트를 정기 점검하는 관점에 더 가깝다.

기술적 SEO 자주 묻는 질문

기술적 SEO만 완벽하면 순위가 오르나요

아니다. 기술적 SEO는 경쟁에 참여할 자격을 얻는 단계이지, 그 자체로 상위 노출을 보장하지 않는다. 콘텐츠 품질, 사용자 신뢰도(E-E-A-T), 백링크 같은 요소가 실제 순위를 결정한다. 다만 기술적 결함이 있으면 나머지 요소가 아무리 좋아도 반영되지 않는다. 비유하자면 기술적 SEO는 경기장에 입장하는 자격이고, 콘텐츠와 신뢰도는 경기 안에서의 실력이다. 입장 자체가 안 되면 실력을 보여줄 기회조차 없다.

이 점검을 얼마나 자주 해야 하나요

사이트 규모에 따라 다르지만, 한 달에 한 번 정도의 정기 점검이 현실적이다. 대규모 개편이나 도메인 이전, 플랫폼 이전 직후에는 더 짧은 주기로 집중 점검하는 것이 안전하며, 특히 URL 구조가 바뀌는 작업 직후에는 리다이렉트가 빠짐없이 걸렸는지부터 다시 확인해야 한다.

개발자가 없는 소상공인은 이걸 다 할 수 있나요

전부 혼자 할 필요는 없다. 서치 콘솔의 크롤링 통계와 URL 검사처럼 클릭 몇 번으로 확인 가능한 항목부터 시작하고, 코어 웹 바이탈이나 구조화 데이터처럼 코드 수정이 필요한 부분은 제작을 맡긴 업체나 전문가에게 정기 점검을 요청하는 방식이 현실적이다. 중요한 것은 모든 항목을 직접 고치는 능력이 아니라, 무엇이 문제인지 알아차리는 눈이다. 문제를 먼저 발견할 수 있으면, 해결은 전문가에게 맡기더라도 무엇을 요청해야 하는지 정확히 전달할 수 있다.

개인 블로그(네이버 블로그 등)도 이 체크리스트가 필요한가요

아니다. 이 체크리스트는 자체 도메인 홈페이지를 기준으로 한다. 네이버 블로그는 네이버가 자동으로 수집·색인하므로 robots.txt, 사이트맵, 서치 콘솔 같은 항목 자체가 해당하지 않는다. 자체 도메인 홈페이지를 운영할 때만 이 순서를 따르면 된다.

우리 사이트가 지금 어느 단계까지 되어 있는지 어떻게 파악하나요

가장 빠른 방법은 서치 콘솔에 로그인해 커버리지(색인 생성) 보고서와 크롤링 통계를 먼저 열어 보는 것이다. 여기서 오류나 경고가 없다면 1–2단계는 통과한 것으로 보고 3단계부터 순서대로 확인하면 된다. 서치 콘솔에 아직 사이트를 등록하지 않았다면, 다른 무엇보다 등록부터 하는 것이 모든 점검의 출발점이다.

기술적 SEO는 한 번 세팅해 두면 끝나는 일이 아니라, 사이트가 커지고 바뀔 때마다 다시 확인해야 하는 기초 유지보수에 가깝습니다. 항목이 많아 막막하게 느껴지신다면, 위 순서대로 하나씩만 짚어 나가셔도 충분합니다. 어디서부터 손대야 할지 판단이 서지 않으신다면, 이루웹에서 기술적 SEO 진단부터 홈페이지 구조 설계까지 함께 점검해 드리고 있습니다. 지금 상태를 먼저 확인해 보고 싶으시다면 이루웹에 무료 상담을 신청해 주시면, 우선순위가 높은 항목부터 정리해서 안내해 드리겠습니다.