우리 사이트, AI 검색에 최적화됐을까? 30분 자가 진단 체크리스트

우리 사이트가 AI 검색에 최적화됐는지 30분 만에 진단할 수 있나요?

우리 사이트가 AI 검색에 최적화됐는지는 도구 없이 브라우저만으로 30분이면 스스로 점검할 수 있습니다. 페이지 소스, 제목·설명, 스키마, 저자 정보, robots.txt, 실제 AI 인용 6가지를 순서대로 확인하면 됩니다.

여기서 말하는 AI 검색 최적화 진단은 ChatGPT·Perplexity·Google AI 개요·네이버 AI 브리핑 같은 생성형 답변에 우리 콘텐츠가 인용되기 좋은 상태인지 확인하는 작업입니다. GEO(생성형 엔진 최적화)는 AI 답변에 인용되도록, AEO(답변 엔진 최적화)는 질문에 곧장 답이 되도록 페이지를 다듬는 일이고, 이 진단은 그 기초 신호를 눈으로 직접 보는 것이라 유료 도구가 없어도 시작할 수 있습니다.

준비물은 웹 브라우저 하나뿐입니다. 크롬·엣지·사파리 어느 것이든 페이지 소스 보기, 주소창 입력, 그리고 ChatGPT·Perplexity 무료 계정만 있으면 됩니다. 설치나 결제, 개발 지식은 필요하지 않습니다. 마케팅 담당자나 대표가 점심시간 안에 자기 사이트의 현재 상태를 스스로 가늠하도록 만든 절차입니다.

이 자가 진단은 정밀 진단이 아니라 방향을 잡는 점검입니다. 6개 영역을 100점으로 정량화하는 체계와 점수를 읽는 법은 GEO 진단 체계에서 따로 다루며, 이 글은 그 여섯 갈래를 도구 없이 손으로 확인하는 실전 절차만 담았습니다. 큰 그림을 빠르게 잡고, 더 정확한 좌표가 필요할 때 정식 진단으로 넘어가면 됩니다.

30분 자가 진단 6가지 항목은 무엇인가요?

AI 검색 자가 진단은 아래 6가지를 순서대로 확인하면 됩니다. 각 항목은 브라우저 기본 기능과 실제 AI 질의만으로 점검하므로 개발 지식이 없어도 됩니다.

1. 본문 텍스트 노출: 화면의 핵심 문장이 페이지 소스에도 그대로 있는지 봅니다. 자바스크립트로만 그려지는 텍스트는 AI 크롤러가 못 읽을 수 있습니다.
2. 제목과 설명: 탭 제목(title)과 meta description이 핵심을 질문·답변형으로 담았는지 확인합니다.
3. 구조화 데이터: 페이지 소스에서 ‘ld+json’을 검색해 Article·FAQPage 같은 JSON-LD 스키마가 있는지 봅니다.
4. 저자 정보: 실명 저자와 소개(E-E-A-T 신호)가 노출되는지 점검합니다. 익명 콘텐츠는 AI가 신뢰 근거로 삼기 어렵습니다.
5. 크롤러 허용: 도메인 뒤 ‘/robots.txt’를 열어 GPTBot·PerplexityBot 같은 AI 크롤러를 막고 있지 않은지 봅니다.
6. 실제 AI 질의: ChatGPT·Perplexity에 우리 브랜드·서비스를 물어보고 답변에 우리 사이트가 인용되는지 봅니다.

시간은 대략 이렇게 나눕니다. 1번부터 5번까지는 페이지 소스와 주소창에서 확인하는 항목이라 한 페이지당 몇 분이면 충분하고, 6번 실제 AI 질의에 10분쯤 남겨 두면 30분 안에 한 바퀴가 돕니다. 여섯 항목 중 ‘아니오’가 몇 개인지 세어 보면 현재 상태가 드러납니다.

특히 1번과 5번은 하나만 막혀도 AI가 사이트 전체를 못 읽는 원인이라 먼저 확인하는 편이 좋습니다. 나머지 항목이 아무리 좋아도 크롤러가 본문에 닿지 못하면 인용은 시작조차 되지 않기 때문입니다. 그래서 이 순서는 읽힘을 먼저, 신뢰와 이해를 그다음, 실제 결과를 마지막에 두도록 짜였습니다.

1번, 본문 텍스트가 페이지 소스에 그대로 있나요?

가장 먼저 볼 것은 화면에 보이는 본문 텍스트가 HTML 소스 안에도 그대로 들어 있는지입니다. AI 크롤러는 사람이 보는 화면이 아니라 서버가 보내 준 소스를 읽기 때문에, 소스에 텍스트가 없으면 아무리 좋은 글도 인용 후보에 오르지 못합니다.

확인하는 방법은 간단합니다. 크롬·엣지에서는 점검할 페이지에서 마우스 오른쪽 버튼을 눌러 ‘페이지 소스 보기’를 선택하거나 단축키(윈도우 Ctrl+U, 맥 Cmd+Option+U)로 바로 열리고, 사파리는 설정에서 개발자용 메뉴를 먼저 켜야 이 항목이 나타납니다. 소스 창이 뜨면 Ctrl+F(맥은 Cmd+F)로 화면에 보이던 핵심 문장 한 구절, 예를 들어 첫 문단의 한 줄이나 제목 일부를 검색합니다.

검색한 문장이 소스에서 그대로 잡히면 정상입니다. 크롤러도 같은 텍스트를 읽을 수 있다는 뜻입니다. 반대로 화면에는 분명히 있는데 소스에서는 찾을 수 없다면, 그 텍스트가 자바스크립트로만 그려지고 있을 가능성이 큽니다. 리액트나 뷰로 만든 일부 사이트가 여기에 해당합니다.

한 페이지만 보지 말고 홈, 서비스 소개, 블로그 글처럼 성격이 다른 페이지를 두세 개 표본으로 확인하는 편이 안전합니다. 어떤 사이트는 블로그만 소스에 텍스트가 담기고 제품 페이지는 비어 있기도 합니다. ‘아니오’가 나온 페이지가 있다면, 그것이 AI 검색 노출을 가로막는 첫 번째 병목입니다.

2번, 제목과 설명이 질문·답변형으로 채워졌나요?

두 번째는 페이지의 제목(title)과 요약 설명(meta description)이 핵심을 담아 채워졌는지입니다. 이 두 요소는 검색 결과와 AI 미리보기에서 사람과 기계가 페이지를 처음 판단하는 근거라, 비어 있거나 모든 페이지가 똑같으면 클릭도 인용도 손해를 봅니다.

제목은 브라우저 탭에 마우스를 올리면 전체가 보이고, 설명은 페이지 소스에서 확인합니다. 소스 보기에서 Ctrl+F로 ‘description’을 검색하면 meta name이 description인 태그의 content 부분이 실제 설명입니다. 더 간단하게는 페이지 링크를 카카오톡이나 슬랙 대화창에 붙여 넣어 보세요. 미리보기 카드에 뜨는 제목과 설명이 바로 그 값입니다.

읽을 때는 세 가지를 봅니다. 제목이 페이지의 핵심 주제나 사용자가 던질 질문을 담고 있는가, 설명이 대략 50자에서 160자 사이에서 페이지 내용을 답변처럼 요약하는가, 그리고 모든 페이지가 같은 문구를 돌려쓰고 있지는 않은가입니다.

설명이 비어 있으면 검색엔진이 본문에서 아무 문장이나 잘라 쓰고, 모든 페이지가 같은 설명을 쓰면 어느 페이지도 또렷하게 구별되지 않습니다. 제목과 설명을 페이지마다 다르게, 질문과 답이 드러나게 채우는 것만으로도 기계가 페이지의 주제를 잡기가 훨씬 쉬워집니다.

3번, 구조화 데이터(스키마)가 페이지에 심겼나요?

세 번째는 구조화 데이터, 곧 JSON-LD 스키마가 페이지에 들어 있는지입니다. 스키마는 이 페이지가 무엇에 관한 글이고 누가 썼는지를 기계가 읽을 수 있는 형식으로 표시한 꼬리표라, 검색 리치 결과와 엔티티 이해를 돕는 기초 신호가 됩니다.

확인은 페이지 소스에서 합니다. Ctrl+F로 ‘ld+json’을 검색하면 됩니다. script 태그에 application/ld+json이 붙은 블록이 나오면 스키마가 있는 것이고, 그 안의 ‘@type’ 값에서 Article, FAQPage, Organization 같은 유형을 확인할 수 있습니다. 소스가 어렵게 느껴지면 구글의 무료 리치 결과 테스트에 페이지 주소를 넣어 감지된 스키마를 표로 볼 수도 있습니다.

해석은 이렇습니다. 스키마가 하나도 없으면 보강 대상이고, Organization과 Article 정도만 있고 FAQPage나 HowTo 같은 용도별 스키마가 없으면 특화 여지가 남은 것입니다. 다만 구글은 생성형 AI 검색에 구조화 데이터가 필수는 아니라고 밝히므로(Google 검색 센터, 2025), 없다고 절망할 일도 있다고 안심할 일도 아닌 기초 신호로 보면 됩니다.

한 가지 주의가 있습니다. 워드프레스에 RankMath 같은 SEO 플러그인을 쓰면 스키마가 소스에 자동으로 들어가는 경우가 많습니다. 겉보기에 없어 보여도 실제로는 심겨 있을 수 있으니, 짐작하지 말고 소스에서 ‘ld+json’을 직접 검색해 확인하세요. 코드로 스키마를 채우는 실전 방법은 JSON-LD와 llms.txt 설정법에 예시로 정리해 두었습니다.

4번, 실명 저자와 소개가 노출되나요?

네 번째는 글을 누가 썼는지가 페이지에 드러나는지입니다. 실명 저자와 소개는 경험·전문성·권위·신뢰를 뜻하는 E-E-A-T 신호의 핵심이라, AI는 누가 썼는지 분명한 콘텐츠를 더 안전하게 인용합니다.

확인은 눈으로 시작합니다. 글의 위나 아래에 저자 이름, 직함, 한 줄 소개가 있는지 보고, 저자 이름을 눌렀을 때 프로필 페이지로 연결되는지 봅니다. 소스에서 ‘author’를 검색하면 스키마의 author 필드에 이름이 들어 있는지도 확인할 수 있습니다.

실명과 직함, 간단한 경력이나 프로필이 갖춰져 있으면 좋은 상태입니다. 반대로 작성자가 ‘관리자’나 ‘admin’으로만 표시되거나 아예 없으면, AI가 그 글을 신뢰의 근거로 삼기 어렵습니다. 특히 전문성을 다투는 주제일수록 익명은 불리하게 작용합니다.

저자 정보는 콘텐츠의 신뢰를 페이지 안에서 증명하는 몇 안 되는 장치입니다. 이름과 직함, 프로필 링크를 붙이는 것만으로도 같은 글의 인용 가능성이 달라지므로, 익명으로 나가고 있다면 우선순위 높은 보완 대상으로 잡아 두는 편이 좋습니다.

5번, robots.txt가 AI 크롤러를 막고 있지 않나요?

다섯 번째는 robots.txt 파일이 AI 크롤러의 접근을 막고 있지 않은지입니다. robots.txt는 어떤 크롤러가 사이트의 어디를 읽어도 되는지 적어 둔 안내문이라, 여기서 AI 봇을 막고 있으면 콘텐츠가 아무리 좋아도 그 AI에는 통째로 보이지 않습니다.

확인은 주소창 한 줄이면 끝납니다. 브라우저 주소창에 우리 도메인 뒤에 ‘/robots.txt’를 붙여 입력합니다. 예를 들어 도메인이 example.com이면 example.com/robots.txt로 들어가면 됩니다. 화면에 뜬 내용에서 Ctrl+F로 ‘GPTBot’, ‘PerplexityBot’, ‘ClaudeBot’, ‘Google-Extended’ 같은 이름을 검색합니다.

해석의 핵심은 ‘Disallow’입니다. 특정 봇 이름 아래에 ‘Disallow: /’가 적혀 있으면 그 봇에게 사이트 전체를 막고 있다는 뜻입니다. 이런 규칙이 없거나 ‘Disallow’가 비어 있으면 열려 있는 상태입니다. 파일 자체가 없어 화면에 404가 떠도 대개는 막지 않은 것으로 봅니다.

한 가지 더 있습니다. robots.txt가 열려 있어도 보안 플러그인이나 방화벽이 AI 봇을 차단하는 경우가 있어, 이 항목을 통과했다고 크롤러 접근이 온전히 보장되지는 않습니다. 다만 robots.txt는 가장 흔하고 확인하기 쉬운 차단 지점이라 자가 진단 단계에서 먼저 봅니다.

6번, 실제 AI에 물었을 때 우리 사이트가 인용되나요?

마지막은 앞의 다섯 항목이 실제 결과로 이어지는지, 곧 AI에 직접 물었을 때 우리 사이트가 답변에 등장하는지입니다. 이 항목은 원인이 아니라 결과 지표라, 나머지 다섯을 고친 효과가 실제로 나타나는지 확인하는 자리입니다.

방법은 이렇습니다. ChatGPT의 검색 모드나 Perplexity에 우리 브랜드와 서비스를 여러 각도로 물어봅니다. ‘우리 브랜드명은 어떤 회사인가’, ‘이 분야에서 추천할 만한 곳’, ‘우리 서비스 카테고리와 지역’을 묶은 질문을 던지고, 답변 본문과 출처 링크에 우리 이름이나 도메인이 나오는지 봅니다.

브랜드명을 직접 넣었는데도 우리가 안 나오면 발견성이 약한 것이고, 카테고리 질문에 경쟁사만 나오면 인용 조건에서 밀리고 있는 것입니다. AI 답변은 질문과 시점에 따라 매번 달라지므로, 한 번으로 단정하지 말고 여러 질문과 여러 번의 시도로 큰 경향을 봅니다.

이 실측이 왜 우리만 빠지는지 원인까지 짚어 주지는 않습니다. 브랜드명으로도 등장하지 않는 상태라면, 그 원인을 단계별로 확인하는 방법을 AI 검색에 회사가 안 나오는 이유에서 이어서 다룹니다. 6번은 진단의 끝이자, 개선 효과를 다시 재는 출발점이기도 합니다.

여섯 항목을 점검한 뒤 무엇부터 고쳐야 하나요?

점검이 끝났다면, 크롤링을 막는 기술 문제부터 풀고 신뢰와 이해를 돕는 항목을 그다음에 손보는 순서가 효율적입니다. 노출의 전제인 ‘읽힘’을 확보해야 나머지 최적화가 비로소 의미를 갖기 때문입니다.

우선순위는 다음 세 단계로 정합니다.

1. 읽힘 확보: 1번 본문 노출과 5번 크롤러 허용을 먼저 해결합니다. 이 둘 중 하나만 막혀도 다른 개선이 효과를 내지 못하므로 가장 앞에 둡니다.
2. 신뢰와 이해 보강: 3번 스키마와 4번 저자 정보, 2번 제목·설명을 채웁니다. 기계가 페이지의 주제와 신뢰도를 파악하도록 돕는 항목입니다.
3. 결과 확인과 반복: 6번 실제 인용은 앞 단계를 고친 뒤 몇 주에서 몇 달의 시차를 두고 다시 확인합니다. AI가 바뀐 사이트를 다시 읽는 데 시간이 걸리기 때문입니다.

실제로 GEOMKT가 자사 사이트를 같은 방식으로 점검했을 때도, 스키마·메타·저자 같은 기본기는 갖췄지만 html lang, og:image, llms.txt, FAQ 스키마 같은 특화 항목에서 개선점 다섯 가지가 나왔습니다. GEO를 다루는 사이트조차 세부 항목엔 손볼 곳이 있었고, 지금도 하나씩 고쳐 가는 중입니다. 그 과정은 GEO 셀프 진단 실전기에 기록해 두었습니다.

자가 진단은 방향을 잡아 주지만 한계도 분명합니다. 여섯 항목을 눈으로 훑는 것만으로는 놓치는 신호가 생기고, 각 영역을 점수로 환산해 우선순위와 수정안까지 스스로 내기는 어렵습니다.

6개 항목 중 세 개 이상이 문제로 나왔거나 정확한 좌표가 필요하다면, GEOMKT 무료 AI 검색 진단으로 현재 상태와 개선 순서를 확인하는 것부터 시작할 수 있습니다. 자가 점검이 방향이라면, 정식 진단은 그 방향 위의 정확한 지점을 찍어 줍니다.

자주 묻는 질문 (FAQ)

Q1. 자가 진단에 정말 도구가 하나도 필요 없나요?

웹 브라우저 하나면 충분합니다. 페이지 소스 보기, robots.txt 확인, ChatGPT·Perplexity 질의는 모두 무료 기능입니다.

유료 도구는 더 정밀하고 여러 페이지를 한꺼번에 훑어 주지만, 방향을 잡는 기초 6개 항목은 도구 없이도 대부분 판별됩니다. 정확한 점수와 우선순위가 필요한 단계에서 전문 도구나 정식 진단으로 넘어가면 됩니다.

Q2. 페이지 소스에서 텍스트가 안 보이면 무조건 문제인가요?

대체로 점검이 필요한 신호지만, 한 페이지만 보고 단정하기는 이릅니다. 사이트에 따라 블로그 글은 소스에 담기고 제품 페이지만 자바스크립트로 그려지는 경우가 있기 때문입니다.

성격이 다른 페이지 두세 개를 표본으로 확인하고, 여러 곳에서 본문이 소스에 없다면 그때 개선 대상으로 봅니다. 한 페이지만 비어 있다면 그 페이지부터 살펴보면 됩니다.

Q3. 스키마가 없으면 AI 검색에 아예 인용되지 않나요?

그렇지 않습니다. 구글은 생성형 AI 검색에 구조화 데이터가 필수는 아니라고 밝힙니다(Google 검색 센터, 2025).

다만 스키마는 검색 리치 결과와 엔티티 이해를 돕는 기초 신호라 갖추는 편이 유리합니다. 특히 FAQPage나 HowTo 같은 용도별 스키마는 답변엔진이 질문과 답을 짝지어 읽기 좋게 만들어 줍니다.

Q4. 실제 AI에 물었을 때 경쟁사만 나오면 어떻게 하나요?

브랜드명으로도 우리가 안 나오고 경쟁사만 나온다면, 발견성과 인용 조건 양쪽을 함께 점검해야 합니다. 대개는 1번 읽힘과 5번 크롤러 접근 같은 기술 문제, 또는 저자·스키마 같은 신뢰 신호가 원인입니다.

한 번의 결과가 아니라 여러 질문의 경향으로 판단하는 것이 먼저입니다. 원인을 스스로 좁히기 어렵다면 30분 무료 상담에서 지금 상황을 듣고 진단이 필요한지부터 말씀드립니다.

Q5. 30분 자가 진단과 전문 GEO 진단은 무엇이 다른가요?

자가 진단은 방향을 잡는 6개 항목의 빠른 점검이고, 전문 진단은 여러 평가 영역을 정밀 측정해 점수와 우선순위, 수정안을 문서로 제공합니다.

진단이 어떤 기준으로 점수를 매기는지는 GEO 진단 체계에서, 리포트에 실제로 어떤 항목이 담기는지는 진단 리포트 항목 공개에서 확인할 수 있습니다. 처음에는 자가 진단으로 시작하고, 정확한 좌표가 필요할 때 정식 진단으로 넘어가면 됩니다.

[참고] Google Search Central 구조화 데이터·AI 검색 가이드(2025), 네이버 AI 브리핑(2025), GEOMKT 자사 GEO 진단 보고서(2026).

실제 적용 결과는 사이트 환경에 따라 달라질 수 있습니다.