mason
mason-log.

SEO와 AEO.

mason

masonfe-hyunsu

🧭 1. 개요.

SEO와 AEO — 검색 노출과 AI 답변

  • 예전에는 키워드를 넣고 검색결과 링크를 고르는 흐름이 중심이었다.

  • 지금은 같은 질문이 AI 개요, 어시스턴트, 음성비서, 앱 내 검색으로 재가공되어 나온다.

  • 노출이 한 포털에 머물지 않고 MCP(Multi-Channel Presence, 여러 채널에 동시에 존재하는 상태)로 넓어진다.

  • 그만큼 문서가 색인(검색엔진이 나중에 찾아쓸 수 있게 내용을 저장해 두는 일)되는 것과 답변으로 뽑히는 것을 같이 봐야 한다.

이 포스팅에서는 SEO(Search Engine Optimization, 검색결과에 잘 보이도록 페이지를 다듬는 일)와 AEO(Answer Engine Optimization, AI 답변에 채택되도록 콘텐츠를 다듬는 일)가 어디서 갈라지는지, 프론트엔드에서 손댈 수 있는 경계를 정리해 본다.

🔀 2. SEO와 AEO.

구분

SEO

AEO

정의

검색엔진에 잘 노출되도록 구조, 콘텐츠를 최적화

AI 응답 시스템에서 답변으로 채택되도록 최적화

목표

색인 후 SERP(Search Engine Results Page, 검색결과 화면) 상위 노출

질문의 직접적인 '답'으로 선택

저장 감각

페이지(문서) 단위

엔티티(사람, 회사, 제품처럼 구분되는 대상), 사실, 관계(지식 조각)

  • SEO는 Blue Link(파란 제목 링크), 스니펫(결과 아래 짧은 요약), 랭킹 신호가 핵심이다.

  • AEO는 FAQ, 정의 문단, JSON-LD(페이지 의미를 기계가 읽기 쉽게 붙이는 구조화 데이터)처럼 LLM(Large Language Model, 글을 이해하고 생성하는 AI 모델)이 잘라 쓰기 좋은 조각이 핵심이다.

  • 둘 다 같은 크롤링(봇이 웹페이지를 돌아다니며 문서를 가져오는 일)에서 시작하지만, 실무에서는 문서 단위 노출과 지식 조각 추출로 나눠 보는 편이 편하다.

SEO와 AEO 비교

SEO는 문서를 올리고, AEO는 지식을 올린다.

🕷️ 3. 수집에서 순위까지.

Google이 공개한 흐름은 Crawling → Indexing → Serving(수집 → 색인 → 결과 제공)이다. 실무 노트에서는 그 사이에 분석(Processing) 을 두고 네 단계로 나눠 봤다.

세부 랭킹 로직은 대부분 비공개다. 조작 방지, 스팸 대응, 정책 변경 여지를 남기기 위해서다. 그래서 우리가 손댈 수 있는 쪽은 문서가 어떻게 읽히게 생겼는지에 가깝다.

검색 파이프라인

수집 (Crawling).

  • 크롤러는 고유 User-Agent(봇이 자신을 밝힐 때 쓰는 이름 문자열)로 페이지를 방문한다. (Googlebot, bingbot, Yeti, GPTBot 등)

  • URL 후보는 sitemap.xml(사이트 지도, 크롤러에게 주요 URL 목록을 알려 주는 파일), 과거 방문, 내부 링크에서 모인다.

  • robots.txt(크롤러 출입 규칙 파일)로 허용된 URL만 Crawl Queue(다음에 방문할 URL 대기열)에 들어가고, 정적 문서를 가져온다.

  • 둘 다 필수는 아니다. sitemap이 없으면 링크 탐색에 더 기대고, robots가 없으면 기본은 허용으로 본다.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/

분석 (Processing).

  • 먼저 정적 HTML을 본다.

  • 의미가 부족하면 JS 렌더링을 지원하는 엔진은 렌더 결과까지 본다. (JavaScript SEO)

  • CSR(Client-Side Rendering, 브라우저에서 JS로 화면을 그리는 방식)만 쓰면 초기에 텍스트가 비어 색인이 밀리거나 실패하는 케이스가 많다.

  • 이때 뽑히는 신호는 Title, Meta, Heading, alt, Canonical(같은 내용의 대표 URL을 가리키는 표시)뿐 아니라 JSON-LD, FAQ, 엔티티 관계, 문서 의도(Intent)까지 갈라진다.

  • SEO 쪽은 문서 요약, 링크, 헤딩 구조가 중심이고, AEO 쪽은 엔티티, 사실, 관계, Q→A 조각이 중심이다.

색인 (Indexing).

  • SEO 쪽(문서 관점): 페이지 레코드. URL, Title, Description, Heading 요약, 본문 요약, 링크, CWV(Core Web Vitals, 로딩, 안정, 반응 같은 핵심 체감 성능 지표) 신호.

  • AEO 쪽(실무 비유): 지식 그래프처럼 엔티티와 사실, 관계를 조각으로 보는 모델. isA, foundedYear, PublisherOf 같은 속성 감각.

  • SEO는 페이지를 한 덩어리로, AEO는 페이지를 잘게 쪼개 지식 조각으로 보는 감각이다.

  • noindex(이 페이지를 검색결과에 넣지 말라는 지시)는 문서 노출을 막지만, 지식 조각이 완전히 무시된다고 단정하긴 어렵다.

순위 (Ranking).

  • SEO는 문서 품질, 링크, 성능 신호로 순위를 매긴다.

  • AEO는 엔티티, 사실, 관계 기반의 답변 품질을 우선한다.

🛠️ 4. 기획, 개발에서 챙길 점.

모든 페이지에 SEO/AEO를 다 걸 필요는 없다. 먼저 대상 페이지를 선별하는 게 효율적이다.

  • 인앱 웹뷰, 로그인 뒤 화면, 실험용 랜딩은 크롤러를 막을 이유가 더 클 수 있다.

  • FAQ, 설명형, 사양, 기업/제품 소개 페이지는 AEO 우선 후보다.

  • 국내 서비스면 Google과 Naver를, 글로벌이면 Google과 Bing을 우선 전제로 두면 실무 판단이 단순해진다. (점유율 참고: StatCounter)

SEO 쪽.

  • 콘텐츠 충분성: 주제, 정보량, 중복, 일관성. 메타나 마크업보다 영향이 큰 편이다

  • 시맨틱 구조: H1~H3, 문단, 섹션으로 "무슨 문서인지" 전달

  • Title / Meta Description: CTR(Click-Through Rate, 노출 대비 클릭 비율)에 직접 영향

  • SSR / SSG: SSR(Server-Side Rendering, 서버에서 HTML을 만들어 내려주는 방식), SSG(Static Site Generation, 빌드 때 HTML을 미리 만들어 두는 방식). HTML에 실제 텍스트가 있어야 색인이 안정적

  • Core Web Vitals: LCP, CLS, INP 등 성능 신호

  • robots / sitemap: 색인 가능 여부의 전제. 내부 링크로 닿기 어려운 중요 URL은 sitemap에 넣는 편이 안전하다

  • 내부 링크: 크롤 효율과 색인률에 직결

  • 외부 링크, 도메인 신뢰: 영향은 크지만 단기 조작이 어렵다. 기대치만 맞추면 된다

AEO 쪽.

  • JSON-LD (schema.org): 엔티티-속성을 직접 연결. 엔티티 이해와 rich result(검색결과에 별점, FAQ처럼 풍부하게 보이는 형태)에 구조화 단서를 줄 수 있다

  • Entity-based writing: 개념, 속성, 관계를 문장에서 명확히 쓰는 방식

  • FAQ (Q → A): LLM이 질문-답 쌍을 그대로 쓰기 쉬움

  • 한 문단 정의: "이게 무엇인지"를 짧게 박아 두는 chunk(LLM이 잘라 저장, 참조하는 의미 단위)

  • 표, 리스트, 비교표: 구조화된 정보는 chunking(의미 단위로 쪼개기)에 유리

  • 문장 명료성: 짧고 사실 중심. 비유와 수식어를 줄이면 추출이 쉽다

개발 체크포인트

Organization 타입 JSON-LD 예시는 대략 이런 형태다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com",
  "description": "글로벌 게임 퍼블리싱 및 플랫폼 서비스"
}
</script>

예전에는 title, description, og(소셜/미리보기용 메타) 정도면 충분했다. 지금은 본문 구조와 함께 schema.org 포맷의 JSON-LD를 같이 넣는 쪽이 맞다.

⚠️ 5. 피해야 할 함정.

  • 잘못된 리다이렉트, 과도한 hop(거쳐 가는 중간 이동), 권역 분기가 크롤 경로를 꼬이게 한다.

  • 글로벌 서비스에서 CloudFront Function 등으로 국가/권역 분기를 걸면, 사람 브라우저와 크롤러의 응답이 달라질 수 있다.

  • 라이브에서 권역 분기 때문에 의도하지 않은 검색결과가 나온 적이 있었다. robots.txt Allow만으로 안심하면 안 된다. IP, 엣지 정책이 따로 막을 수 있다.

  • 크롤러는 기본적으로 정적 문서를 가져온다. User-Agent 분기가 필요하면 CF Function, Lambda@Edge처럼 JS 렌더 이전 단계에서 해야 한다.

📊 6. 실제로 오는 크롤러.

라이브 트래픽을 CloudFront + CloudWatch로 7일간 집계해 보면, 검색봇만 오는 게 아니다.

  • Googlebot, bingbot뿐 아니라 MJ12bot, GPTBot(OpenAI 쪽 수집 봇) 계열, Yandex, Yeti, AhrefsBot, CCBot 등이 섞인다.

  • 목적이 다르다. 검색 색인봇, 학습 데이터 수집봇, 링크 그래프(누가 누구를 링크했는지 보는 분석) 봇이 한 로그에 같이 찍힌다.

  • 예를 들어 MJ12bot(Majestic)은 본문 색인보다 링크 관계, 도메인 신뢰도 계산 쪽에 가깝다.

  • 하루 수백 건이어도 무시할 수준은 아니다. 검색봇 외 수집봇까지 섞여 들어온다는 신호로 보면 된다.

  • SEO 대상이 아닌 경로라면 차단을 검토할 수 있다. 초점은 불필요한 색인, 잘못된 노출, SSR, API처럼 요청당 비용이 큰 경로를 봇이 반복 치는 쪽에 둔다.

✅ 7. 체크리스트.

  • [ ] 이 페이지는 SEO가 필요한가 / AEO가 필요한가

  • [ ] robots.txt, sitemap.xml 제출(Search Console, Search Advisor)

  • [ ] Title, Meta, og, Heading, 본문 텍스트가 HTML에 존재하고 내용이 충분한가

  • [ ] 페이지 유형에 맞는 JSON-LD

  • [ ] FAQ 또는 명확한 Q&A, 한 문단 정의

  • [ ] 이미지 alt, 내부 링크, Canonical / hreflang(언어, 지역별 대응 페이지 표시)

  • [ ] 권역, 리다이렉트 정책이 크롤러 응답을 왜곡하지 않는지

🔗 8. 참고 자료.

이전 글
npm, Yarn, pnpm.
다음 글
Debounce와 Throttle.

댓글

불러오는 중...
목록으로