AEO 적용 사례: 메타 태그와 구조화 데이터를 직접 확인하기

AEO를 위해서는 질문에 답하는 본문과 실제 페이지 출력을 함께 확인해야 합니다. 메타 태그나 구조화 데이터가 본문을 대신하지는 않습니다. 태그를 모두 넣었다고 AI 답변에 인용되는 것도 아닙니다.

이 글은 준이아빠블로그의 구현을 사례로 각 설정의 역할을 설명합니다. 처음에는 코드를 수정하지 않고 브라우저에서 제목과 대표 주소만 찾아 봅니다. 그다음 구조화 데이터와 사이트 안내 파일을 읽습니다. 내 사이트의 코드를 직접 바꾸려면 사용하는 편집 도구나 개발 환경에 맞춘 작업이 필요합니다.

AEO와 GEO의 뜻부터 구분하기

AEO(Answer Engine Optimization, 답변 엔진 최적화)는 검색과 AI 답변에서 콘텐츠가 정확히 이해되고 참고되도록 개선하는 작업입니다. GEO(Generative Engine Optimization, 생성형 엔진 최적화)는 생성형 AI 답변에서의 노출을 다루며 AEO와 겹치는 범위가 있습니다. FAQ는 자주 묻는 질문과 답을 뜻합니다. 특정 제품을 두 종류로 딱 나누거나 FAQ가 있으면 AEO가 완성된다고 보지는 않습니다.

SEO(Search Engine Optimization, 검색엔진 최적화)는 검색엔진이 페이지를 찾고 이해하도록 개선하는 작업입니다. Google AI 검색도 검색에 포함될 수 있는 페이지와 유용한 본문이 기본이며, 별도 AI 파일이나 특별한 구조화 데이터가 필수는 아닙니다. Google AI 검색 안내

GEO 논문은 연구 환경에서 콘텐츠를 보강해 답변 내 가시성 지표를 최대 40% 개선한 결과를 제시했습니다. 이 결과를 메타 태그 설치의 효과나 모든 사이트와 현재 제품의 인용률 상승으로 확대할 수는 없습니다. GEO 논문

먼저 제목과 대표 주소 찾기

컴퓨터의 Chrome이나 Edge에서 이 글을 엽니다. 휴대전화만 있다면 아래 코드 예시에서 제목과 주소를 읽는 연습을 먼저 하고, 소스 확인은 컴퓨터에서 이어 갑니다. 본문 빈 곳을 오른쪽 클릭해 페이지 소스 보기를 선택하면 새 탭에 HTML이 나타납니다. HTML은 브라우저가 웹페이지를 표시할 때 읽는 문서이며 <title> 같은 표시는 그 문서의 항목을 구분하는 태그입니다. 메뉴의 “검사”는 개발자 도구이므로 처음에는 “페이지 소스 보기”를 선택합니다.

소스 탭에서 Windows는 Ctrl+F, Mac은 Command+F로 찾기를 엽니다. 아래 세 문자열을 하나씩 찾습니다.

대표 주소는 같은 내용이 여러 주소로 열릴 때 검색엔진에 우선 사용할 주소로 제안하는 URL입니다. 이 글의 주소는 https://www.digitalmarketer.co.kr/insights/aeo-geo-practical-setting-case입니다. 제목에 사이트 이름이 함께 붙을 수 있으므로 글자 하나까지 예시와 같아야 하는 것은 아닙니다.

메모에 “화면의 글 제목 / 소스의 title / description 설명 / canonical 주소”를 한 줄씩 적습니다. 이 글이라면 제목은 AEO 설정 확인을 다루고, 설명도 같은 주제를 안내하며, 대표 주소 끝은 /aeo-geo-practical-setting-case여야 합니다. 제목이 다른 글이거나 canonical이 관계없는 페이지를 가리킨다면 정상으로 넘기지 않습니다. 다시 연 주소가 맞는지 확인하고, 자기 사이트라면 편집 설정 또는 템플릿을 관리자와 확인합니다. 소스에서 값을 찾지 못했다고 바로 본문을 다시 쓸 필요는 없습니다. 먼저 description이나 canonical만 검색해 따옴표나 공백 차이 때문인지 봅니다. 본문의 설명용 코드가 아니라 실제 <meta>와 <link> 태그의 값을 확인합니다. 소스에서는 본문 코드의 꺾쇠가 <처럼 표시될 수 있습니다.

이 확인은 어떤 정보가 출력됐는지 알아보는 연습입니다. Google에 색인됐다는 뜻은 아닙니다. 색인은 검색엔진이 페이지 정보를 검색에 사용할 수 있도록 저장하는 과정이며, 권한이 있는 사이트는 Google 검색 상태와 실적을 보는 도구인 Search Console의 URL 검사로 상태를 확인할 수 있습니다.

메타 태그가 하는 일

메타데이터는 본문 외에 제목, 설명과 공유 이미지 같은 페이지 정보를 적는 데이터입니다. HTML의 <head>는 이런 정보를 담는 영역입니다. 일부 정보가 문서 앞에 있다는 사실이 AI가 그 정보를 가장 중요하게 평가한다는 뜻은 아닙니다.

준이아빠블로그는 원고 맨 앞의 제목과 설명 같은 항목을 읽어 태그를 만듭니다. 이 원고 속성 부분을 frontmatter라고 합니다. 웹페이지를 만드는 Next.js의 generateMetadata() 함수가 이를 처리합니다. 코드를 쓰지 않는 블로그에서는 관리 화면의 검색 설명이나 공유 이미지 항목이 비슷한 역할을 할 수 있습니다.

아래는 읽기 쉽게 줄인 예시입니다. 전체 소스를 그대로 복사한 것은 아니며, 출력 순서와 따옴표 모양은 다를 수 있습니다.

• title과 description은 제목과 설명을 제공합니다. 검색 결과의 제목이나 요약은 검색엔진이 다르게 구성할 수도 있습니다.
• canonical은 대표 주소를 제안하는 신호입니다. 검색엔진에 강제하는 명령이나 중복을 자동 삭제하는 기능은 아닙니다. Google 대표 주소 안내
• og 태그는 Open Graph 형식의 공유 정보입니다. 링크를 공유할 때 제목과 이미지 미리보기를 만드는 데 사용됩니다.
• twitter 태그는 X의 공유 카드 정보를 제공합니다. 실제 모양은 서비스의 처리와 저장된 미리보기 등에 따라 달라질 수 있습니다.

현재 코드에는 keywords 메타 태그도 있지만 Google은 이 태그를 색인이나 순위에 사용하지 않는다고 명시합니다. 다른 서비스가 활용한다는 근거 없이 필수 설정으로 권하지는 않습니다. Google 메타 태그 안내

검색 제목과 공유 제목을 똑같이 써도 됩니다. 공유 맥락에 더 적절한 문구가 있을 때 구분해서 씁니다. 둘을 다르게 만들기만 하면 클릭률이 오른다고 단정하지 않습니다.

구조화 데이터는 페이지 정보를 적는 양식입니다

구조화 데이터는 글의 제목, 작성자, 질문과 답 등을 정해진 항목으로 적은 정보입니다. Schema.org는 이런 항목과 유형을 정의하는 어휘를 제공합니다. 준이아빠블로그는 그 정보를 JSON-LD 형식으로 적습니다. 아래 코드에서 따옴표 안의 항목 이름과 콜론 뒤의 값이 짝을 이룹니다. 예를 들어 "headline": "글 제목"은 제목 값을 적는 방식입니다. 페이지의 자기소개 양식이라고 생각하면 됩니다.

소스에서 application/ld+json을 찾으면 해당 데이터를 담은 스크립트를 볼 수 있습니다. JSON-LD는 <head>나 <body> 안에 들어갈 수 있으며, 준이아빠블로그의 글 화면은 페이지 구성 안에서 이 스크립트를 출력합니다. 무조건 <head>에만 있어야 하는 것은 아닙니다.

Article: 글의 기본 정보

아래는 이 글의 구조화 데이터에서 역할을 설명하기 위해 간추린 예시입니다. 실제 데이터에는 작성자, 발행자와 그 밖의 항목도 함께 있습니다.

headline은 제목, datePublished는 발행 시점, dateModified는 수정 시점입니다. 내용이 바뀌지 않았는데 날짜만 최신으로 바꾸지 않습니다. @type은 정보의 유형을 나타냅니다.

Article 정보가 있으면 검색엔진이 글의 제목, 이미지와 날짜 등을 이해하는 데 도움이 될 수 있습니다. 그러나 작성자 필드 하나가 비어 있다는 이유로 모든 신뢰 판단 근거가 사라지는 것은 아닙니다. 작성자 정보와 본문의 근거도 함께 중요합니다. Google Article 안내

BreadcrumbList: 사이트 안의 경로

BreadcrumbList는 “홈 → 글 → 현재 글” 같은 사이트 내부 경로를 설명합니다. 처음 들어온 사람이 이 글이 어디에 속하는지 이해하는 데 도움이 됩니다. 이 설정만으로 클릭률이 오른다고 판단하지는 않습니다.

FAQPage: 본문에서 질문과 답을 가져오기

준이아빠블로그의 src/lib/extract-faq.ts는 물음표로 끝나는 H2와 H3 소제목을 질문으로 보고 그 아래 첫 문단을 답으로 묶습니다. H2와 H3는 HTML 소제목의 단계입니다. 답변은 20자를 초과해야 하며, 유효한 쌍이 하나 이상이면 글 페이지가 FAQPage를 발행합니다. 특정 관심 유도 소제목은 제외하고 표, 글머리 목록과 이미지 줄은 건너뛰는 자체 구현입니다.

소제목만 질문형으로 바꾸면 모든 사이트가 같은 데이터를 만들지는 않습니다. 해당 추출 코드나 기능을 제공하는 도구가 있어야 합니다. 또한 질문 바로 밑에 표를 두면 표 뒤의 엉뚱한 문단이 답으로 선택될 수 있어 출력 확인이 필요합니다.

다음은 이 글 마지막의 질문 하나를 표시하는 예시입니다.

질문의 name과 답변의 acceptedAnswer.text를 화면의 질문과 답에 대조합니다. acceptedAnswer.text는 acceptedAnswer 안에 있는 text 값을 가리키는 표기입니다. 질문 수가 늘었다는 이유만으로 개선됐다고 보지 않습니다. 자연스러운 소제목을 전부 질문으로 바꿀 필요도 없습니다.

Google은 2026년 5월 7일부터 FAQ 리치 결과를 표시하지 않는다고 안내했습니다. FAQPage를 유지해 질문과 답을 기술할 수는 있지만, Google 검색 화면의 FAQ 노출을 기대하며 넣는 설정으로 설명해서는 안 됩니다. Google 변경 기록

공개 페이지는 Schema.org 검사기에 URL을 넣어 구조화 데이터 형식을 검사할 수 있습니다. 결과의 FAQPage 항목을 펼쳐 mainEntity 아래 질문의 name과 acceptedAnswer 안의 text를 확인합니다. 비공개 정보가 들어 있는 페이지 소스를 외부 검사기에 붙여 넣지 않습니다. 오류가 0개여도 내용의 사실성이나 AI 인용을 확인한 것은 아닙니다. 없는 항목을 억지로 채우기보다 화면의 내용과 데이터가 같은지 먼저 봅니다.

사이트맵과 robots.txt의 역할

사이트맵은 검색엔진에 페이지 주소 목록을 알려 주는 파일입니다. robots.txt는 자동으로 페이지를 수집하는 크롤러에게 수집 규칙을 알립니다. 둘이 있어도 모든 페이지가 수집되거나 검색에 포함되는 것은 아닙니다.

준이아빠블로그의 현재 robots.txt 중 공통 규칙과 사이트맵 부분을 간추리면 다음과 같습니다. 개별 크롤러용 허용 규칙도 별도로 출력됩니다.

User-agent: *는 공통 적용 대상, Allow: /는 전체 경로 수집을 허용한다는 뜻입니다. 이 예시를 모든 사이트에 그대로 붙여 넣지는 않습니다. 기존 수집 정책과 별도 크롤러 규칙을 먼저 확인해야 합니다. robots.txt는 로그인이나 접근 권한을 대신하는 보안 장치가 아니며, 차단된 주소가 검색에서 반드시 사라지는 것도 아닙니다. Google robots.txt 안내

AI 크롤러도 목적이 다릅니다. OpenAI의 GPTBot은 모델 학습에 사용할 수 있는 콘텐츠를 수집하고 OAI-SearchBot은 ChatGPT 검색을 위한 크롤러입니다. 두 설정은 독립적이므로 GPTBot을 차단했다고 ChatGPT 검색에서 자동 제외되는 것은 아닙니다. 검색에 포함되고 싶은 경우에도 해당 서비스의 검색 크롤러 정책을 먼저 확인합니다. OpenAI 크롤러 안내

사이트맵 인덱스인 /sitemap.xml은 하위 사이트맵의 목록입니다. /sitemap/0.xml에는 인사이트 글, /sitemap/1.xml에는 클래스와 코스 및 다른 공개 경로가 들어갑니다. 나누는 목적은 목록을 관리하기 위한 것이며 그 자체가 순위 상승 조건은 아닙니다.

loc는 글의 주소, lastmod는 마지막으로 실질적인 내용을 수정한 시점입니다. 현재 사이트 코드에는 changefreq와 priority도 있지만, Google은 이 두 값을 무시한다고 명시합니다. 값을 0.5에서 0.8로 바꾸었다고 Google의 색인이 빨라진다고 설명할 수 없습니다. Google 사이트맵 안내

llms.txt는 선택해서 제공하는 안내 파일입니다

llms.txt는 AI 도구가 사이트 자료를 찾기 쉽도록 간단한 설명과 링크를 제공하자는 제안 형식입니다. 2024년 9월에 제안됐고, 2026년 8월의 v2도 제안 문서로 공개돼 있습니다. Google 검색의 필수 파일이거나 모든 AI가 반드시 읽는 규격은 아닙니다. llms.txt 제안 문서

준이아빠블로그의 파일에는 사이트 소개, 전문 분야와 선별한 주요 자료 링크가 들어갑니다. 다음은 형식을 설명하기 위해 간추린 예시입니다.

파일을 제공한다면 링크가 열리는지, 설명과 현재 사이트가 맞는지 유지해야 합니다. 없어도 일반 링크나 사이트맵 등으로 자료를 찾을 수 있습니다. 파일 하나만으로 주제 권위나 인용 효과가 증명되는 것은 아닙니다.

과거 검색 그래프로 확인할 수 있는 범위

아래는 2026년 4월 원래 글을 작성할 때 남긴 Search Console 추이 화면입니다. 현재의 성과 그래프가 아닙니다.

2월 초에는 두 선이 낮은 수준에서 움직이고, 3월 초 상승한 뒤 중순 이후 내려갑니다. 4월에는 다시 높아지는 구간이 보입니다. 다만 세로축 수치와 지표 범례가 없어 이 이미지 하나로 정확한 증가 배수나 클릭률을 계산할 수는 없습니다.

당시에는 FAQ 자동 출력, 사이트맵과 안내 파일 등의 작업을 진행했습니다. 작업 시기와 그래프 변화가 겹친다는 이유만으로 각각의 설정이 상승 원인이라고 확정하지는 않습니다. 특히 Google이 무시하는 사이트맵 priority 값을 성과 원인으로 연결하면 안 됩니다.

실제 효과를 살피려면 같은 페이지의 같은 길이 기간을 비교하고, 노출과 클릭 및 CTR을 함께 기록해야 합니다. CTR은 노출 중 클릭의 비율입니다. 콘텐츠 추가, 검색 수요, 순위와 다른 변경의 영향도 살펴야 합니다. 숫자 읽는 방법은 검색량과 클릭률 및 AI 유입 구분하기에 예시를 넣었습니다.

내 글 한 편에서 다시 확인하기

이제 다른 글 한 편을 열어 처음의 세 항목을 혼자 찾아 봅니다. 제목, 설명과 대표 주소가 그 글을 가리키는지 메모합니다. FAQPage가 있다면 질문 하나와 답 한 문단이 실제 본문과 맞는지도 대조합니다. 없다면 곧바로 오류라고 판단하지 않습니다.

자기 사이트에서 제목이나 설명이 틀렸다면 원고 또는 관리 화면의 해당 항목을 고칩니다. 게시 권한과 검토 절차를 따른 뒤 페이지를 새로 열고 소스의 값이 바뀌었는지 확인합니다. 그대로라면 저장한 버전, 발행 상태와 캐시를 확인할 차례입니다. 원고 파일의 날짜와 실제 공개된 버전이 다를 수도 있습니다. 캐시는 이미 만든 화면이나 정보를 임시 저장한 것입니다. 저장된 이전 값이 보이는 경우에는 현재 발행본과 대조합니다.

이 단계의 완료 기준은 화면과 소스의 내용이 의도한 글을 설명하고 있는지입니다. 이후의 검색 노출과 인용 여부는 별도 기록으로 확인합니다. 1~2주 안에 반드시 성과가 오른다는 식으로 기한을 약속하지 않습니다.

자주 묻는 질문

SEO가 부실한데 AEO부터 해도 될까요?

질문에 답하는 본문은 지금 개선할 수 있습니다. 동시에 페이지가 검색엔진에 전달되고 검색에 포함될 수 있는지도 확인해야 합니다. Google AI 검색에서는 기본 검색 요건이 중요하지만, 모든 AI가 같은 수집 방식과 선정 규칙을 쓰는 것은 아닙니다.

metaTitle과 og:title을 같은 문구로 써도 되나요?

같게 써도 됩니다. 검색과 공유 맥락에 맞춰 다르게 쓸 수는 있지만, 문구를 나누는 것만으로 클릭률이 오르는 것은 아닙니다. 실제 본문과 어긋나지 않는 제목을 먼저 작성합니다.

llms.txt를 올리면 AI가 반드시 읽어 가나요?

보장되지 않습니다. 자료 탐색을 돕기 위한 제안 형식이며, 서비스를 운영하는 쪽이나 도구가 이를 이용해야 역할을 합니다. 파일을 추가했다는 사실과 실제로 수집되거나 인용됐다는 결과를 구분합니다.

3줄 요약

1. AEO는 코드만으로 결정되지 않으며 유용한 본문과 페이지 접근 상태 및 실제 출력 내용을 함께 확인해야 합니다.

2. 메타 태그와 구조화 데이터는 페이지 정보를 설명하지만 검색 노출과 AI 인용을 보장하지는 않습니다.

3. 제목과 대표 주소부터 대조하고 설정을 바꾼 뒤에는 출력 결과와 실제 검색 성과를 나누어 확인합니다.