SEO 최적화 점검 — 블스피가 직접 겪은 색인 사고 7가지

왜 남의 사고 목록이 쓸모 있나

"SEO 최적화 작업"을 맡기면 보통 제목 태그, 키워드 배치, 콘텐츠 보강 같은 보이는 작업이 먼저 나옵니다. 하지만 블스피가 실제로 유입을 잃은 원인은 대부분 보이지 않는 곳에 있었습니다. 브라우저로 열면 멀쩡한 페이지가 크롤러에게는 404이거나, 정본이 다른 URL이거나, noindex였습니다. 아래 일곱 가지는 이 사이트의 코드 주석과 수정 이력에 남아 있는 실제 사례이고, 같은 구조(Next.js 같은 프레임워크, 별도 백엔드, 자동 생성 페이지)를 쓰는 사이트라면 그대로 재현될 수 있습니다.

블스피의 사고 7가지

출처: 블스피 lib/seo.ts·app/robots.ts·app/sitemap.ts 주석과 2026년 8~9월 수정 이력.

가장 비쌌던 사고 — 342개 noindex 껍데기

블스피는 키워드마다 측정 데이터를 담은 페이지를 만들어 사이트맵에 실었습니다. 그런데 프레임워크가 주소의 슬러그를 이미 인코딩된 상태로 넘겨주는데 코드가 한 번 더 인코딩하는 바람에 "%"가 "%25"가 되었고, 백엔드는 그런 키워드가 없다며 404를 돌려줬습니다. 데이터가 없으면 페이지는 "키워드를 찾을 수 없습니다"와 함께 noindex를 내보내도록 되어 있었습니다.

결과적으로 사이트맵에 실어 검색엔진에 제출한 URL이 한 장도 빠짐없이 색인 거부 페이지였습니다. 한 달 넘게 발행돼 있던 페이지도 같았습니다. 그동안 난이도 계산을 고치고, 사이트맵을 나누고, RSS를 제출했지만 정작 그 URL들은 한 번도 내용을 보여준 적이 없었습니다. 브라우저 테스트는 다른 경로로 들어가 정상으로 보였기 때문에, 백엔드 접근 로그에 찍힌 "%25EB…"를 보고서야 알아챘습니다.

공식 문서가 말하는 같은 원칙

• ·대표 주소: 네이버는 같은 내용을 여러 URL로 내면 중복 판정을 받는다며 대표 주소로 301 리다이렉트하거나 rel="canonical"을 쓰라고 한다. 구글은 리디렉션과 canonical을 강한 신호, 사이트맵 포함을 약한 신호로 분류한다.
• ·피드의 도메인: 네이버는 사이트맵·RSS 안 URL이 소유확인 도메인과 같아야 제출할 수 있고, 상대경로나 다른 호스트 링크는 수집하지 않는다고 명시한다. 구글도 사이트맵에 정규화된 절대 URL을 쓰라고 한다.
• ·리소스 차단: 네이버는 JS·CSS 경로를 웹 문서와 같은 규칙으로 맞추거나 허용하라고 하고, 구글도 크롤링 차단이 렌더링을 방해할 수 있다고 본다.
• ·응답 코드: 네이버는 없는 페이지에 200을 주는 소프트 404, 점검 중 200 응답을 피하라고 한다. 반대로 정상 페이지가 404나 noindex를 내보내면 그 페이지는 경쟁에 참여조차 못 한다.
• ·robots.txt와 noindex의 역할: 구글은 robots.txt가 노출을 막는 수단이 아니라고 한다. 블스피는 내부 링크가 있는 로그인·대시보드 같은 페이지를 robots.txt로 막지 않고 noindex만 건다. 크롤링을 막으면 noindex를 읽지 못해 주소만 색인될 수 있기 때문이다.

점검 순서 — 화면이 아니라 응답을 본다

• ·대표 URL 10개를 골라 네이버 URL 검사와 구글 URL 검사로 수집·색인 여부, 검색엔진이 고른 정본을 확인한다.
• ·view-source:로 원본 HTML을 열어 canonical, robots 메타, title이 페이지마다 다른지 본다. 자바스크립트 실행 후 화면이 아니라 서버 응답이 기준이다.
• ·robots.txt를 열어 렌더링 리소스 경로(/_next/, /static/ 등)가 막혀 있지 않은지 본다.
• ·사이트맵 안 URL 몇 개를 무작위로 열어 200, index, 자기 자신을 가리키는 canonical인지 확인한다. 사이트맵에 404·noindex·리다이렉트 URL이 섞여 있으면 신호가 흐려진다.
• ·사이트맵으로만 도달하는 고아 페이지가 없는지 본다. 블스피는 키워드 페이지 허브(/keyword)와 푸터 링크를 만들어 내부 링크로도 닿게 했다.