기술적 SEO 4가지 태그를 직접 읽고 설정 오류를 잡는 법 2026
블로그를 운영하다 보면 어느 날 Google Search Console에서 "페이지가 색인되지 않음" 경고를 마주하게 된다. 그때서야 robots.txt가 뭔지 찾아보고, canonical은 왜 있는 건지 헷갈리고, noindex를 잘못 달았을까 봐 불안해진다. 솔직히 나도 처음엔 이 네 가지가 다 같은 말인 줄 알았다.
이 글은 robots.txt, sitemap.xml, canonical, noindex 태그를 브라우저에서 직접 열고 읽어서 내 블로그 설정이 맞는지 틀렸는지 판단하는 스펙 해독 가이드다. "어떻게 설정하나요" 안내가 아니라, 이미 있는 설정을 읽고 진단하는 관점으로 썼다. 브라우저 탭 하나 열어두고 같이 따라가 보면 10분이면 충분하다.
지금 바로 열어볼 URL 세 개
설명보다 먼저 이 순서를 따라가 보자. 세 개 탭을 열면 진단의 절반은 끝난다.
yourdomain.com/robots.txt— 텍스트 파일이 열려야 한다. 404가 뜨면 파일이 없는 것.yourdomain.com/sitemap.xml— XML 트리가 열려야 한다. 빈 화면이면 sitemap이 빠진 것.- 주요 글 페이지에서
Ctrl+U(소스 보기) →Ctrl+F로canonical검색 →rel="canonical"속성이 보이면 있는 것.
세 개 다 열렸는데 뭘 봐야 할지 모르겠다면, 지금부터 각각의 스펙이 실제로 말하는 걸 해독해보자.
robots.txt 스펙이 말하는 것과 블로거들이 오해하는 것
robots.txt는 크롤러가 내 사이트 어느 경로를 방문할 수 있는지 알려주는 파일이다. 루트 도메인(yourdomain.com/robots.txt)에 UTF-8로 작성하며, Google 공식 기준 최대 파일 크기는 500 KiB다. 이 크기를 넘으면 Google이 파일을 잘라 읽는다.
스펙이 말하는 것: robots.txt는 크롤 접근 지시어일 뿐이다.
흔한 오해: "robots.txt로 차단하면 검색 결과에서 사라진다."
이 둘은 다르다. Google은 차단된 URL도 외부 링크를 통해 인지하면 URL만 검색 결과에 노출할 수 있다. 크롤 차단 ≠ 색인 차단이다. 검색 결과에서 페이지를 없애고 싶다면 robots.txt가 아니라 noindex를 써야 한다.
Disallow: / 한 줄만 있는 robots.txt를 본 적 있다면, 그건 전체 크롤을 막는 설정이다. 색인 제거와 혼동해서 달아둔 경우가 꽤 있다.
Allow vs Disallow 충돌 시 우선순위 규칙
| 상황 | 문법 예시 | Google 처리 방식 |
|---|---|---|
| 모든 경로 차단 | Disallow: / | 전체 크롤 차단 (색인 차단 아님) |
| 특정 폴더 차단 | Disallow: /admin/ | /admin/ 하위 경로 전체 차단 |
| 차단 중 예외 허용 | Disallow: /admin/Allow: /admin/style.css | 더 긴(구체적인) 경로가 우선 → style.css 허용 |
| 전체 허용 (기본) | Allow: / | 명시 없으면 허용이 기본값 |
| 확장자 전체 차단 | Disallow: /*.pdf$ | $로 URL 끝 지정 가능 |
충돌이 생길 때 Google은 더 구체적인(긴) 경로 규칙을 따른다. 길이가 같으면 Allow를 우선하는 "least restrictive" 원칙이 적용된다.
robots.txt를 열었을 때 확인할 것:
Disallow: /만 있고 그 아래 Allow가 없다면 전체 크롤 차단 상태다. 의도한 건지 다시 확인해야 한다.- Disallow 경로 목록에 노출하고 싶은 중요 페이지 경로가 포함돼 있진 않은지 훑어본다.
Sitemap: https://yourdomain.com/sitemap.xml줄이 있으면 Google이 sitemap 위치를 여기서도 파악한다.
sitemap.xml 스펙이 말하는 것과 시간 낭비 포인트
sitemap.xml은 내 사이트 페이지 목록을 검색 엔진에 알리는 파일이다. 크롤 효율을 높이는 역할을 하지만, sitemap에 올라간다고 색인이 보장되는 건 아니다.
Google 공식 제한은 단일 sitemap 기준 최대 50,000 URLs 또는 50 MB(비압축)다. 초과하면 sitemap 인덱스 파일(sitemap_index.xml)로 분할해야 한다.
스펙이 말하는 것:
흔한 오해: "priority를 1.0으로 올리면 더 자주 크롤된다."
Google은
sitemap.xml을 열었을 때 확인할 것:
- sitemap URL과 실제 canonical URL이 다르면 신호가 충돌한다. 예를 들어 sitemap에는 HTTP 버전이 올라가 있는데 canonical은 HTTPS 버전을 가리키는 경우다.
- noindex가 걸린 페이지가 sitemap에 포함돼 있으면 Google에 모순 신호를 보내는 셈이다. 색인하지 말라면서 sitemap으로 크롤을 유도하는 구조다.
canonical과 noindex, 공식 스펙이 실제로 말하는 것
canonical 태그는 중복 콘텐츠가 있을 때 대표 URL을 Google에 알리는 방식이다. 안에 아래처럼 넣는다.
<link rel="canonical" href="https://yourdomain.com/real-url/" />noindex는 크롤러가 페이지를 방문하되 검색 결과에 올리지 말라는 지시다.
<meta name="robots" content="noindex">
<meta name="googlebot" content="noindex">소스보기(Ctrl+U)에서 안을 보면 이 두 태그가 있는지, 어떤 값으로 설정됐는지 바로 확인할 수 있다. 그런데 이 두 태그가 함께 쓰이면 헷갈리는 부분이 있다.
스펙이 말하는 것: canonical은 "힌트(hint)"다. Google이 반드시 따를 의무는 없다.
흔한 오해: "canonical만 달면 중복 문제가 해결된다."
canonical이 가리키는 URL이 404를 반환하거나, 리다이렉트 체인을 거치거나, 아예 noindex가 걸려 있으면 Google이 그 힌트를 무시하고 다른 URL을 대표로 선택한다. 소스보기에서 canonical href 값을 복사해 직접 열어보면 이 문제를 바로잡을 수 있다.
소스보기에서 확인할 것 다섯 가지:
- 자기참조 canonical 누락: 모든 발행 페이지는 자기 자신을 canonical로 지정해야 한다. 없으면 Google이 임의로 다른 URL을 대표로 선택할 수 있다.
- canonical이 리디렉션 URL 또는 404를 가리킴: canonical은 반드시 직접 접근 가능한 200 응답 페이지여야 한다.
- canonical + noindex 모순: noindex가 달린 페이지를 canonical로 지정하면 Google이 그 페이지를 색인하지 않는 모순이 생긴다.
- HTTP·HTTPS canonical 혼용: 발행된 URL이 HTTPS인데 canonical이 HTTP를 가리키면 신호가 희석된다.
- 상대 경로 canonical:
href="/real-url/"같은 상대 경로는 일부 환경에서 오인식된다. 반드시https://...절대 URL로 쓴다.
robots.txt와 noindex를 같이 달면 생기는 문제 ⚠️
놓치면 가장 손해가 큰 조합이다. robots.txt로 차단한 경로에 noindex를 함께 달면 noindex가 작동하지 않는다. 크롤러가 robots.txt 차단으로 페이지 자체에 접근하지 못하니, 안의 noindex 태그를 읽을 수 없기 때문이다. 결과적으로 그 페이지가 외부 링크를 통해 URL만 검색 결과에 노출될 수 있다.
목적에 따라 도구를 맞게 고르면 된다.
| 목적 | 올바른 도구 | 잘못된 조합 |
|---|---|---|
| 크롤 예산 절약 (세션 ID·정렬 파라미터 URL) | robots.txt Disallow | — |
| 검색 결과에서 완전 제외 (관리자 페이지·임시 페이지) | noindex 단독 | robots.txt + noindex 동시 |
| 크롤은 허용하되 색인만 막기 | noindex 단독 | robots.txt Disallow 추가하면 noindex 무효화 |
| 페이지 내용 자체를 숨기기 | 비밀번호 보호 | robots.txt·noindex 모두 부적절 |
워드프레스라면 설정 → 읽기 → "검색 엔진이 이 사이트를 색인하지 못하도록 막기" 체크박스가 활성화되어 있으면 전체 사이트가 noindex 처리된다. 소스보기에서 가 보인다면 이 설정을 먼저 확인해야 한다. 초기 개발 단계에 켜놓고 해제를 잊은 채 운영하는 경우가 상당히 많다.
플랫폼마다 스펙을 직접 건드릴 수 없는 부분이 있다
어떤 플랫폼에서 운영하느냐에 따라 위 4가지를 직접 수정할 수 있는 범위가 갈린다. 이걸 모르면 "설정을 고쳐야 하는데 왜 안 되지"라는 상황이 생긴다.
| 기능 | 워드프레스 (자체 호스팅) | 티스토리 | 네이버 블로그 |
|---|---|---|---|
| robots.txt 직접 수정 | 가능 (파일 직접 편집) | 불가 (플랫폼 자동 생성) | 불가 |
| canonical 태그 설정 | 가능 (Yoast SEO 등 플러그인) | 불가 (플랫폼 자동 생성) | 불가 |
| 개별 페이지 noindex | 가능 (플러그인 또는 직접) | 불가 | 불가 |
| sitemap 직접 제어 | 가능 (생성·제출 직접) | 부분 가능 (Search Console 제출만) | 불가 |
| 구조화 데이터(JSON-LD) | 가능 | 불가 (테마 수정으로 부분 가능) | 불가 |
| 페이지 속도 최적화 | 가능 (플러그인·호스팅 선택) | 제한적 | 불가 |
티스토리는 플랫폼이 robots.txt를 자동 생성한다. 스킨 에디터에서 파일을 올려도 루트가 아니라 /images/ 하위에 저장돼 실제로 적용되지 않는다. 개별 포스트 단위로 canonical을 직접 변경하는 방법도 공식 제공이 안 된다. 네이버 블로그는 기술적 SEO 설정을 사용자가 직접 제어하는 방법이 없다. 구글 기준 기술적 SEO를 본격적으로 다루고 싶다면, 워드프레스 자체 호스팅이 사실상 유일한 선택지다.
참고자료
이 글이 도움이 됐나요?
여러분의 반응이 다음 글의 방향이 돼요
