GEONIQ

좋은 콘텐츠를 만들고 페이지 구조까지 정리했는데도 검색에서 잘 보이지 않을 수 있다. 이유는 단순하다. 검색엔진이 그 페이지를 찾지 못했거나, 읽지 못했거나, 검색 결과 후보로 저장하지 않았을 수 있다.

GEO에서도 같은 문제가 생긴다. AI가 답변에 브랜드나 콘텐츠를 포함하려면 먼저 접근 가능한 상태로 열려 있을 때 후보에 들어간다. 크롤러가 막혀 있거나, 핵심 본문이 JavaScript 실행 뒤에만 나오거나, canonical과 sitemap 신호가 서로 다르면 좋은 글도 답변 후보가 되기 어렵다.

Technical SEO/GEO는 콘텐츠 성과를 받치는 기술 기반이다.

발견 → 크롤링 → 렌더링 → 인덱싱 → 이해 → 노출 또는 인용

이 과정 중 하나가 막히면 콘텐츠는 제 역할을 못 한다.

개발자는 “브라우저에서 잘 보이는데?”라고 말하기 쉽다. 사용자가 보는 화면에서는 문제가 없어 보일 수 있다. 하지만 검색엔진과 AI 크롤러는 브라우저 사용자와 같은 방식으로 사이트를 경험하지 않는다.

특히 프론트엔드 기반 사이트에서는 아래 문제가 자주 생긴다.

사람에게 보이는 화면만 확인하면 이런 문제를 놓친다. Technical SEO/GEO는 크롤러 기준으로 다시 보는 작업이다.

검색엔진과 AI가 페이지를 보려면 URL을 먼저 발견한다. 좋은 글을 써도 내부 링크가 없고 sitemap에도 없으면 사이트 구조 안에서 찾기 어렵다.

발견을 막는 대표 원인은 아래와 같다.

기본 점검은 간단하다.

사이트맵에 넣는 것만으로는 부족하다. 중요한 페이지라면 내부 링크로도 연결한다.

검색엔진이 페이지를 방문했다고 해서 반드시 검색 결과에 넣지는 않는다. 크롤링은 페이지를 가져오는 일이고, 인덱싱은 검색 결과 후보군에 저장하는 일이다.

인덱싱에 영향을 주는 요소는 다양하다.

인덱싱 문제가 생겼다고 전부 개발 이슈는 아니다. 기술적으로 열려 있어도 콘텐츠가 너무 얇거나, 거의 같은 페이지가 여러 개 있거나, 대표 URL 신호가 충돌하면 인덱싱되지 않을 수 있다.

그래서 Search Console 같은 도구로 색인 제외 이유를 확인하고, 기술 문제와 콘텐츠 문제를 나눠 본다.

Technical SEO에서 자주 터지는 문제는 제어 신호를 잘못 쓰는 것이다.

역할은 이렇게 나뉜다.

robots.txt는 크롤링 제어다. 인덱스 차단 도구로 쓰면 위험하다. 이미 외부 링크 등으로 알려진 URL은 내용은 읽히지 않아도 검색 결과에 남을 수 있다.

noindex 확인도 크롤러가 페이지를 읽을 수 있는 상태에서 가능하다. robots.txt로 막아놓고 noindex를 넣으면 검색엔진이 noindex 태그를 확인하지 못할 수 있다.

canonical도 명령이 아니라 힌트다. canonical은 A를 가리키는데 내부 링크와 sitemap은 B를 가리키면 대표 URL 판단이 어려워진다.

React, Vue, Next.js 같은 프레임워크를 쓰는 사이트에서는 JavaScript SEO를 별도로 확인한다. 특히 콘텐츠 중심 페이지, 랜딩 페이지, 문서 페이지는 초기 HTML과 링크 구조를 먼저 본다.

점검할 질문은 아래와 같다.

구글은 JavaScript 렌더링을 처리할 수 있다. 하지만 모든 크롤러가 같은 수준으로 처리한다고 보면 안 된다. AI 관련 크롤러까지 고려하면 핵심 정보는 가능한 한 안정적으로 노출되는 편이 낫다.

GEO에서는 기존 검색엔진 크롤러뿐 아니라 AI 관련 크롤러도 본다. 정책상 허용할지 차단할지는 서비스 전략에 따라 달라질 수 있다. 문제는 의도 없이 막거나, 의도 없이 열어두는 것이다.

대표적으로 검토할 수 있는 크롤러는 아래와 같다.

모든 크롤러를 무조건 허용하라는 뜻은 아니다. 다만 AI 답변 노출을 기대한다면 어떤 크롤러가 어떤 경로에 접근할 수 있는지 알아야 운영 기준을 정할 수 있다.

robots.txt 예시는 이렇게 확인한다.

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Allow: /

이런 설정은 학습용 크롤러와 사용자 요청 기반 크롤러를 다르게 다루는 정책이다. 의도한 설정인지 확인한다.

XML sitemap은 검색엔진에게 URL 목록을 알려주는 힌트다. 하지만 sitemap에 들어 있다고 인덱싱이 보장되는 것은 아니다.

좋은 sitemap은 아래 조건을 가진다.

사이트맵이 오래된 URL, 리디렉션 URL, noindex URL로 가득하면 오히려 신호가 지저분해진다.

중요한 페이지는 sitemap에도 넣고, 내부 링크로도 연결한다. sitemap은 목록이고, 내부 링크는 사이트 구조다.

Core Web Vitals는 SEO 보고서에 나오는 숫자처럼 보이지만, 실제로는 사용자가 페이지를 읽을 수 있는지에 가깝다.

대표 지표는 아래와 같다.

속도를 망치는 원인은 대체로 반복된다.

기술 점수를 100점으로 만드는 것이 목표는 아니다. 독자가 기다리지 않고 본문을 읽을 수 있는 상태가 기준이다. AI 크롤러 입장에서도 서버가 안정적으로 응답하고 본문을 빠르게 제공하는 쪽이 낫다.

구조화 데이터는 페이지의 의미를 더 분명하게 전달하는 장치다. 순위를 올리는 마법은 아니지만, 검색엔진이 콘텐츠 유형과 관계를 이해하는 데 도움을 준다.

자주 쓰는 유형은 아래와 같다.

가장 큰 원칙은 본문과의 일치다. 본문에는 FAQ가 없는데 FAQPage 스키마를 넣거나, 실제 제품 정보와 다른 Product 스키마를 넣으면 오히려 문제가 된다.

JSON-LD를 적용했다면 리치 결과 테스트나 Schema Validator로 오류를 확인한다.

사이트는 운영할수록 URL 문제가 쌓인다. 삭제된 글, 바뀐 slug, 태그 페이지, 필터 URL, 추적 파라미터, 오래된 리디렉션이 계속 생긴다.

상태코드 기본은 아래와 같다.

흔한 실수도 정해져 있다.

작은 블로그에서는 당장 큰 문제가 아닐 수 있다. 하지만 페이지 수가 늘면 크롤링 효율과 인덱스 품질에 영향을 준다.

발행 전이나 사이트 점검 시 아래 항목을 확인한다.

GEONIQ이 Technical SEO/GEO에서 보는 것은 “좋은 콘텐츠가 실제로 읽힐 수 있는 상태인가”에 가깝다.

검색엔진과 AI 크롤러가 접근하지 못하거나, 핵심 콘텐츠가 렌더링 이후에만 나오거나, canonical과 sitemap 신호가 충돌하면 콘텐츠는 검색과 AI 답변의 후보가 되기 어렵다.

점검 질문은 아래처럼 정리할 수 있다.

크롤러가 중요한 페이지에 접근할 수 있는가?
핵심 본문과 링크가 안정적으로 노출되는가?
대표 URL 신호가 한 방향으로 정렬되어 있는가?
AI 관련 크롤러 접근 정책이 의도와 맞는가?
구조화 데이터와 본문 내용이 일치하는가?
운영 중 생긴 URL 문제가 방치되어 있지 않은가?

이 질문에 답하지 않은 상태에서 콘텐츠만 늘리면 성과가 제한된다. 검색과 AI 답변 노출은 접근 가능한 원문에서 시작한다.

Technical SEO/GEO는 개발자 취향의 디테일 정리가 아니다. 좋은 페이지가 발견되고, 읽히고, 인덱싱되고, 대표 URL로 신호가 모이게 만드는 기반 작업이다.

검색엔진도 AI도 접근할 수 없는 콘텐츠를 답변에 쓸 수 없다. 그래서 기술 구조는 콘텐츠보다 뒤에 있는 일이 아니라, 콘텐츠가 성과를 내기 위한 전제에 가깝다.

AI 답변 노출을 말할 때도 기술 기반은 빠지지 않는다. 크롤링, 인덱싱, 렌더링, canonical, sitemap, 구조화 데이터가 어긋나면 좋은 콘텐츠도 발견되기 어렵다.

GEONIQ은 사이트 URL을 기준으로 검색엔진과 생성형 AI가 콘텐츠를 읽고 답변 후보로 삼을 수 있는 상태인지 함께 확인한다. 콘텐츠 품질만이 아니라 접근성, 대표 URL 신호, AI 크롤러 정책까지 같은 점검 흐름 안에서 본다.