AI 검색 노출을 위한 홈페이지 진단 25가지 기준

AI 검색 노출을 점검할 때 많은 담당자가 가장 먼저 robots.txt나 JSON-LD를 확인합니다. 두 항목은 중요하지만 로봇 접근 허용이나 구조화 데이터 적용만으로 홈페이지가 답변의 출처 또는 브랜드 정보로 활용되는 것은 아닙니다.

검색엔진과 AI 시스템이 사이트를 이해하려면 어떤 회사가 운영하는지, 각 페이지가 어떤 질문에 답하는지, 대표 URL이 무엇인지, 작성 주체와 수정일을 확인할 수 있는지, 어떤 근거를 사용했는지와 관련 문서가 어떻게 연결되는지를 함께 읽을 수 있어야 합니다.

GEO는 이러한 기술 구조와 콘텐츠·신뢰 정보를 질문 맥락에 맞춰 점검하고 보강하는 운영 방식입니다. 기본 개념과 SEO와의 차이는 ‘GEO란 무엇인가?’ 가이드에서 확인하고, 이 글에서는 홈페이지 자체의 진단 항목에 집중합니다.

진단의 목적은 25개 항목을 모두 통과시키거나 보기 좋은 점수를 만드는 것이 아닙니다. 중요한 질문과 연결된 공식 페이지에서 수집을 막는 문제, 주제 이해를 어렵게 하는 문제와 신뢰 근거가 부족한 문제를 찾아 수정 순서를 정하는 것이 핵심입니다.

구조화 데이터, robots.txt 또는 특정 메타태그 하나만으로 AI 인용이 보장되지는 않습니다. 수집 접근성, 페이지 주제, 운영 주체, 콘텐츠 근거와 문서 간 관계가 함께 일관되어야 합니다.

접근 차단 문제를 콘텐츠 품질보다 먼저 확인합니다. 페이지가 존재하는 것과 색인 가능한 것은 다르고, 브라우저 화면에 보이는 것과 초기 HTML에 출력되는 것도 다릅니다. 메타데이터와 JSON-LD 역시 존재 여부뿐 아니라 실제 본문과 일치하는지를 나누어 봐야 합니다.

공개형 결과는 ‘즉시 개선’, ‘우선 보강’, ‘정상 또는 관찰’로 구분할 수 있습니다. robots 차단이나 공개 페이지의 noindex처럼 접근·색인에 직접 영향을 줄 수 있는 항목은 즉시 개선 대상으로 보고, 설명과 근거가 약한 항목은 중요한 페이지부터 우선 보강합니다.

진단 점수보다 사업상 중요한 페이지를 먼저 봅니다. 수정 후에는 동일 URL의 서버 응답, 초기 HTML, metadata와 JSON-LD를 다시 검사하고 실제 색인과 검색 결과 반영에는 시간이 필요할 수 있음을 기록합니다. 발견된 항목 하나를 미노출의 단일 원인으로 단정하지 않습니다.

다음 표는 공개 가능한 25개 진단 항목을 수집·이해·신뢰 관점에서 요약한 것입니다. 정상 신호는 통과 보증이 아니라 현재 확인 가능한 상태이며, 문제 신호는 추가 검증이 필요한 관찰 결과입니다.

수집·색인·서버 그룹은 콘텐츠를 평가하기 전에 확인합니다. 설정 파일이 정상처럼 보여도 실제 요청이 막힐 수 있으므로 파일 내용, 응답 헤더와 서버 동작을 분리해 검사합니다.

확인하는 것: User-agent: * 규칙, Disallow 오설정, sitemap 선언, 주요 크롤러 규칙과 도메인·경로를 봅니다. 왜 중요한가: robots.txt는 크롤러가 접근할 URL 범위를 안내하지만 색인이나 AI 인용을 보장하지 않습니다. 문제 신호: 공개 페이지 또는 렌더링 자산이 차단되거나 다른 도메인의 sitemap이 선언됩니다. 개선 방향: 필요한 공개 경로만 허용하고 불필요한 규칙을 정리합니다. 검증 방법: robots.txt 원문과 대상 URL의 실제 요청 결과를 함께 확인합니다.

확인하는 것: 서버 방화벽, CDN·WAF, 국가별 차단, 반복 요청 제한, CAPTCHA, 403·429 응답과 User-Agent별 정책을 봅니다. 왜 중요한가: robots.txt가 Allow여도 보안 계층이 요청을 거부하면 본문을 가져갈 수 없습니다. 문제 신호: 일반 브라우저는 열리지만 특정 요청이 차단되거나 로그인·챌린지 화면으로 바뀝니다. 개선 방향: 보안을 유지하면서 공식 문서로 확인 가능한 크롤러와 공개 페이지의 합리적 접근 정책을 정합니다. 검증 방법: 서버 로그와 동일 URL의 상태·응답 본문을 비교합니다.

확인하는 것: meta robots, X-Robots-Tag, 페이지별 noindex, staging 설정과 canonical 충돌을 검사합니다. 왜 중요한가: noindex는 크롤링 트래픽을 다루는 robots.txt와 달리 검색 색인 제외를 지시하는 수단입니다. 문제 신호: 공개 페이지 HTML이나 응답 헤더에 noindex가 남아 있습니다. 개선 방향: 공개 의도를 확인한 뒤 meta와 헤더 설정을 함께 수정합니다. 검증 방법: 초기 HTML head와 HTTP 응답 헤더를 직접 읽고 환경별 결과를 비교합니다.

확인하는 것: 공개 URL 포함, 200 응답, 정상 XML, canonical URL, lastmod, 중복과 404·redirect·noindex URL 제외 여부를 봅니다. 왜 중요한가: sitemap은 발견할 URL과 변경 정보를 전달하지만 제출만으로 색인이나 순위가 보장되지는 않습니다. 문제 신호: 비공개·중복·다른 호스트 URL이 섞이거나 실제 수정과 무관한 lastmod가 반복됩니다. 개선 방향: 공개 정본 URL만 유지합니다. 검증 방법: XML 파싱 결과를 실제 페이지 상태와 대조합니다.

확인하는 것: HTTPS 인증서, 200 상태, 301·302 체인, www·non-www, trailing slash, HTTP→HTTPS, redirect loop와 soft 404를 봅니다. 왜 중요한가: 여러 URL 변형과 긴 이동 경로는 대표 문서 해석과 안정적인 접근을 어렵게 할 수 있습니다. 문제 신호: 같은 페이지가 여러 호스트로 열리거나 최종 URL까지 반복 이동합니다. 개선 방향: 한 대표 호스트와 짧은 영구 리디렉션을 사용합니다. 검증 방법: 최초 요청부터 최종 200까지 상태와 Location 헤더를 기록합니다.

렌더링·접근성·기술 그룹은 브라우저에서 보이는 결과와 수집 시점의 문서가 같은지 확인합니다. 소스, 렌더링된 DOM과 모바일 화면을 각각 봐야 합니다.

확인하는 것: 페이지 소스의 H1·핵심 본문, JavaScript 실행 전 내용, 무한 스크롤, 클릭 후 로드, API 오류와 hydration 오류를 봅니다. 왜 중요한가: 화면에서 보이는 콘텐츠가 초기 HTML에는 없을 수 있고 실행 실패 시 빈 문서가 될 수 있습니다. 문제 신호: 셸만 출력되고 중요한 답변은 클라이언트 요청 뒤에 나타납니다. 개선 방향: 핵심 설명을 서버 렌더링 또는 정적 HTML로 제공합니다. 검증 방법: 원본 HTML과 렌더링 후 DOM을 비교합니다.

확인하는 것: 초기 서버 응답, 로드 실패, 타임아웃, 과도한 이미지, 레이아웃 이동, hydration 오류와 모바일 네트워크 상태를 봅니다. 왜 중요한가: 특정 속도 점수보다 요청할 때마다 핵심 본문이 안정적으로 제공되는지가 중요합니다. 문제 신호: 간헐적 5xx, 빈 화면, 장시간 대기나 큰 요소 이동이 반복됩니다. 개선 방향: 서버 오류와 핵심 자산 병목부터 줄입니다. 검증 방법: 여러 조건에서 상태 코드와 본문 제공 여부를 반복 확인합니다.

확인하는 것: viewport 설정, 가로 넘침, 표·코드 블록, CTA, 글자 크기, 모바일 메뉴와 이미지 잘림을 봅니다. 왜 중요한가: 모바일에서 내용이 잘리면 사용자와 수집 시스템 모두 문서 관계를 확인하기 어려워질 수 있습니다. 문제 신호: 페이지 전체가 좌우로 밀리거나 버튼과 표 열이 화면 밖에 고정됩니다. 개선 방향: 표는 자체 가로 스크롤을 제공하고 본문 폭을 제한합니다. 검증 방법: 320px부터 주요 중단점에서 실제 조작과 가로 overflow를 확인합니다.

확인하는 것: html lang, 본문 언어, 다국어 페이지, hreflang이 있다면 대상 URL과 언어 코드를 봅니다. 왜 중요한가: 문서 언어는 읽기 도구와 검색 시스템이 페이지 맥락을 해석하는 기본 단서입니다. 문제 신호: 한국어 본문에 다른 언어 코드가 지정되거나 언어별 페이지가 같은 canonical을 잘못 공유합니다. 개선 방향: 실제 콘텐츠와 URL 정책에 맞게 언어 정보를 통일합니다. 검증 방법: 최종 HTML의 lang·hreflang·canonical을 함께 대조합니다.

확인하는 것: 의미 있는 이미지 alt, 장식 이미지의 빈 alt, 파일명, 캡션, 로고 설명과 텍스트를 이미지에만 넣는지 봅니다. 왜 중요한가: alt는 이미지가 전달하는 의미를 대체하며 키워드 반복 칸이 아닙니다. 문제 신호: 모든 이미지에 같은 문구가 들어가거나 긴 스크린샷만 있고 본문 설명이 없습니다. 개선 방향: 이미지 목적을 간결히 설명하고 핵심 정보는 HTML 텍스트로도 제공합니다. 검증 방법: 이미지를 보지 않고도 문맥을 이해할 수 있는지 확인합니다.

메타데이터와 헤딩은 페이지의 대표 주제를 설명합니다. 각 요소가 존재하는지만 세지 않고 서로 같은 질문과 URL을 가리키는지 확인합니다.

확인하는 것: 페이지별 고유 제목, 브랜드명, 핵심 주제, 중복 title과 template 중복을 봅니다. 왜 중요한가: title은 문서의 대표 주제를 짧게 식별하는 메타정보입니다. 문제 신호: 여러 페이지가 ‘홈페이지’나 ‘게시물’처럼 같은 제목을 쓰거나 브랜드명이 두 번 붙습니다. 개선 방향: 페이지의 핵심 질문과 브랜드를 자연스럽게 구분합니다. 검증 방법: HTML title과 사이트 전체 중복 목록을 확인합니다.

확인하는 것: 페이지 내용 요약, 브랜드·서비스, 중복·빈 값, 과장 문구와 본문 일치를 봅니다. 왜 중요한가: description은 페이지 내용을 설명하는 메타정보이지 노출을 보장하는 순위 공식이 아닙니다. 문제 신호: 모든 페이지가 같은 광고 문구를 쓰거나 실제 본문에 없는 서비스를 약속합니다. 개선 방향: 페이지가 답하는 질문과 범위를 구체적으로 요약합니다. 검증 방법: 최종 meta 값과 첫 화면 본문을 대조합니다.

확인하는 것: self-referencing canonical, 다른 URL·도메인, http·https, www, 파라미터와 sitemap 불일치를 봅니다. 왜 중요한가: canonical은 중복 후보 중 선호하는 대표 URL을 알리는 신호입니다. 문제 신호: 상세 글이 목록이나 다른 글을 canonical로 가리키고 내부 링크는 또 다른 URL을 사용합니다. 개선 방향: 실제 정본 정책에 맞춰 canonical·sitemap·OG·내부 링크를 통일합니다. 검증 방법: 최종 HTML 링크와 모든 URL 신호를 비교합니다.

확인하는 것: og:title, og:description, og:url, og:type, og:image, og:site_name, 절대경로와 이미지 응답을 봅니다. 왜 중요한가: Open Graph는 주로 공유 미리보기와 문서 식별을 돕는 메타정보입니다. 문제 신호: 다른 페이지 제목·URL이 남거나 이미지가 404입니다. 개선 방향: 현재 페이지와 일치하는 절대 URL과 대표 이미지를 사용합니다. 검증 방법: HTML meta와 각 자산의 HTTP 응답을 확인하며 그 자체가 AI 인용을 보장하지 않는다고 해석합니다.

확인하는 것: 명확한 H1, 페이지 주제, title과 의미 일치, 숨김·복수 H1과 이미지 안의 제목을 봅니다. 왜 중요한가: H1은 화면에서 사용자가 확인하는 대표 제목입니다. 문제 신호: H1이 없거나 시각적으로 숨겨지고 카드 제목이 무질서하게 H1로 반복됩니다. 개선 방향: 핵심 질문을 설명하는 화면 제목을 둡니다. 검증 방법: 렌더링 DOM에서 보이는 H1 개수와 내용을 확인합니다.

확인하는 것: H1→H2→H3 순서, 디자인용 오용, 질문형 소제목, 목차 연결과 빈 heading을 봅니다. 왜 중요한가: 헤딩은 긴 본문의 정보 관계와 하위 질문을 설명합니다. 문제 신호: 글자 크기를 위해 heading을 건너뛰거나 내용 없는 제목이 반복됩니다. 개선 방향: 대표 질문 아래에 같은 수준의 주제와 세부 기준을 배치합니다. 검증 방법: heading만 읽어도 문서 흐름이 성립하는지 확인합니다.

콘텐츠·문서 관계 그룹은 글자 수보다 질문 해결력과 페이지 사이의 연결을 봅니다. 빠른 답변, 충분한 근거와 내부 링크가 같은 사용자 의도를 지원해야 합니다.

확인하는 것: 도입부의 핵심 답변, 질문 반복, 정의·비교·조건, 요약 박스와 결론 일치를 봅니다. 왜 중요한가: 빠른 결론은 짧은 문장 하나가 아니라 사용자의 핵심 질문에 먼저 답하는 구조입니다. 문제 신호: 배경 설명과 광고가 길고 답은 마지막에만 나옵니다. 개선 방향: 결론·조건·한계를 먼저 제시하고 뒤에서 근거를 설명합니다. 검증 방법: 첫 화면만 읽어도 글의 답과 범위를 이해할 수 있는지 확인합니다.

확인하는 것: 제목과 본문 일치, 핵심·하위 질문, 구체적 설명, 예시·조건·한계와 광고성 문장을 봅니다. 왜 중요한가: 글자 수가 길어도 질문을 해결하지 못하면 주제 이해와 사용자 가치가 약합니다. 문제 신호: 키워드만 반복하거나 제목과 다른 서비스 홍보가 대부분입니다. 개선 방향: 사용자가 판단하는 데 필요한 조건과 근거를 추가합니다. 검증 방법: 제목에서 예상되는 질문 목록과 실제 답변 문단을 대응시킵니다.

확인하는 것: 비교표, 단계 목록, 체크리스트, 화면 FAQ, 표 하단 해석, 모바일 표와 FAQPage 일치를 봅니다. 왜 중요한가: 구조 요소는 정보의 비교·순서·관계를 명확히 해야 합니다. 문제 신호: 키워드 반복용 표가 추가되거나 화면 답변과 schema 답변이 다릅니다. 개선 방향: 실제 본문에 필요한 구조만 사용하고 해석 문장을 붙입니다. 검증 방법: 모바일 조작과 화면·JSON-LD 질문 및 답변의 일치를 확인합니다.

확인하는 것: 핵심·허브 페이지, 고아 페이지, 의미 있는 앵커, broken link, draft·hidden 링크와 문맥 관계를 봅니다. 왜 중요한가: 내부 링크는 페이지 사이의 주제 관계와 대표 콘텐츠를 설명합니다. 문제 신호: ‘자세히 보기’만 반복되거나 비공개·관련 없는 페이지로 연결됩니다. 개선 방향: 독자가 다음에 확인할 목적을 앵커에 명시합니다. 검증 방법: 링크 응답과 공개 상태를 확인하고 페이지 관계도를 검토합니다.

신뢰·운영 주체·구조화 데이터 그룹은 화면에서 확인 가능한 사실과 기계가 읽는 설명이 일치하는지 봅니다. 존재하지 않는 개인 작성자나 외부 채널을 만들지 않습니다.

확인하는 것: author, publisher, datePublished, dateModified, 화면과 JSON-LD 일치, 작성 주체 소개를 봅니다. 왜 중요한가: 누가 언제 책임지고 작성·수정했는지 확인할 수 있어야 정보의 맥락을 판단할 수 있습니다. 문제 신호: 임의 전문가 이름을 쓰거나 실제 수정 없이 날짜만 최신으로 바꿉니다. 개선 방향: 실제 개인이 없다면 확인 가능한 조직을 작성·발행 주체로 표시합니다. 검증 방법: 화면 날짜와 Article JSON-LD 값을 대조합니다.

확인하는 것: 회사 소개, 공식 회사명, 한글·영문 브랜드, 대표자·연락처, URL, 서비스 범위, 푸터와 외부 표기를 봅니다. 왜 중요한가: 운영 주체 정보가 페이지마다 다르면 브랜드와 공식 문서의 연결이 약해질 수 있습니다. 문제 신호: 같은 사이트에서 여러 회사명이 섞이거나 문의 정보가 다릅니다. 개선 방향: 첫 언급은 써밋피드(SUMMITFEED), 이후는 써밋피드처럼 정본 표기를 정합니다. 검증 방법: About·푸터·홈·외부 공식 채널을 대조합니다.

확인하는 것: Organization의 name·alternateName·url·logo·@id·sameAs, WebSite의 publisher·inLanguage와 중복 출력을 봅니다. 왜 중요한가: 전역 엔터티는 사이트 운영 주체와 웹사이트 관계를 보완합니다. 문제 신호: 화면에 없는 회사 정보, 확인되지 않은 sameAs, 오래된 로고나 여러 @id가 섞입니다. 개선 방향: 실제 화면과 공식 URL에 있는 값만 사용합니다. 검증 방법: 페이지별 JSON-LD를 수집해 Organization과 WebSite 중복·연결을 확인합니다.

확인하는 것: headline, author, publisher, 날짜, mainEntityOfPage, image, Breadcrumb, FAQ 일치, 중복 schema와 페이지 유형을 봅니다. 왜 중요한가: 구조화 데이터는 문서와 사이트 계층을 기계가 이해하도록 돕지만 화면과 달라서는 안 됩니다. 문제 신호: 화면에 없는 FAQ를 추가하거나 AboutPage를 Article로 표시합니다. 개선 방향: 페이지 유형에 맞는 최소한의 정확한 타입을 연결합니다. 검증 방법: 파싱·검증 도구와 화면 내용을 함께 대조합니다.

확인하는 것: 공식 문서, 자체 경험·원본 데이터, 출처 URL, 긴 직접 인용, 동일 원고 복사, 여러 도메인의 중복, canonical, 데모·실제 데이터와 광고 고지를 봅니다. 왜 중요한가: E-E-A-T는 schema 하나가 아니라 경험·전문성·외부 확인 가능성·투명성이 사이트 전체에서 연결되는 상태입니다. 문제 신호: 출처 없이 단정하거나 동일 글이 여러 도메인에 정본 구분 없이 복제됩니다. 개선 방향: 공식 1차 자료와 정본 URL을 명시합니다. 검증 방법: 주장별 근거와 중복 URL의 대표 신호를 확인합니다.

llms.txt, RSS 또는 feed, IndexNow, 웹 앱 manifest와 별도 AI 데이터 피드는 운영 목적과 공식 지원 범위를 확인한 뒤 선택적으로 사용할 수 있는 보조 요소입니다. 이 파일이나 제출 방식 하나만 적용한다고 노출 또는 인용이 보장되지는 않습니다.

사이트가 PWA가 아니라면 manifest를 억지로 만들 필요가 없고, llms.txt도 필수 순위 요소로 설명하지 않습니다. 필요한 기능이 없다면 핵심 25개 가운데 접근·대표 URL·본문·운영 주체 정합성을 먼저 보강합니다.

일반적으로 접근·색인 차단, 대표 URL과 리디렉션, HTML 본문과 렌더링, title·canonical·H1, Organization·Article 구조화 데이터, 핵심 질문에 답하는 본문, 작성자·출처·회사 정보, 내부 링크, 중복 콘텐츠, 모바일·성능·보조 요소 순으로 검토할 수 있습니다. 다만 사업상 중요한 페이지와 실제 장애 범위에 따라 순서는 달라집니다.

홈페이지 진단 결과는 타겟 질문, 플랫폼별 브랜드 언급, 출처 인용과 경쟁사 분석표와 함께 볼 때 실제 작업 우선순위를 정하기 쉽습니다.

수집 차단, metadata, JSON-LD, 콘텐츠와 내부 링크 중 어떤 항목부터 개선할지 현재 홈페이지 상태에 맞춰 확인할 수 있습니다.

1. robots.txt Allow만 있으면 인용된다고 생각합니다. robots는 접근 범위를 다루므로 실제 서버 응답, 색인 가능성, 본문과 신뢰 정보를 다시 확인해야 합니다.

2. noindex와 robots.txt를 같은 설정으로 봅니다. robots는 크롤링을, noindex는 색인 제외를 다루므로 파일·HTML·응답 헤더를 분리해 확인해야 합니다.

3. 화면에 보이면 초기 HTML에도 있다고 판단합니다. 페이지 소스와 렌더링 후 DOM을 비교해 핵심 답변이 언제 출력되는지 확인해야 합니다.

4. 모든 페이지에 같은 title과 description을 사용합니다. 페이지별 질문과 본문을 기준으로 고유 메타정보를 작성해야 합니다.

5. canonical을 다른 페이지나 잘못된 호스트로 연결합니다. sitemap, Open Graph와 내부 링크가 같은 대표 URL을 가리키는지 봐야 합니다.

6. JSON-LD에 화면에 없는 정보를 넣습니다. 구조화 데이터는 숨은 홍보 공간이 아니므로 실제 표시된 회사·문서·FAQ 정보만 설명해야 합니다.

7. 화면 FAQ와 FAQPage 답변이 다릅니다. 질문과 답변을 동일한 데이터에서 생성하고 중복 schema가 없는지 확인해야 합니다.

8. 작성자와 수정일 없이 긴 글만 발행합니다. 실제 작성·발행 주체와 변경 이력을 화면과 Article 데이터에 일치시켜야 합니다.

9. 외부 채널에 동일 원고를 그대로 복사합니다. 정본 URL과 채널별 역할을 정하고 중복 문서의 canonical·내용 차이를 검토해야 합니다.

10. 내부 링크 없이 글을 고립시킵니다. 관련 허브와 대표 글에서 문맥에 맞는 링크가 연결되는지 확인해야 합니다.

11. 점수를 높이려고 영향이 작은 항목부터 수정합니다. 접근 차단과 중요한 전환 페이지의 핵심 공백을 먼저 처리해야 합니다.

12. llms.txt 같은 선택 요소를 필수 요소처럼 설명합니다. 공식 지원 범위와 운영 목적을 확인하고 핵심 기술·콘텐츠·신뢰 항목과 구분해야 합니다.