Cloudflare Workers 리버스 프록시로 SEO·AEO 강화하기

Cloudflare Workers 리버스 프록시를 활용하면 원본 애플리케이션을 크게 수정하지 않고도 공개 도메인을 통일하고, SEO와 AEO(Answer Engine Optimization)에 필요한 메타데이터·구조화 데이터·사이트맵을 응답 단계에서 보강할 수 있습니다.

이 글에서는 AllDing 사이트에 적용한 Worker 코드의 구조를 바탕으로, www.allding.co.kr을 공개 주소로 유지하면서 원본 서버의 콘텐츠를 전달하고 검색엔진과 AI 답변 엔진이 이해하기 쉬운 형태로 응답을 재구성하는 방법을 정리합니다.

핵심 요약
요청은 공개 도메인에서 받고 원본 서버로 전달한 뒤, HTML·리다이렉트·텍스트 리소스 안의 URL을 공개 도메인으로 다시 씁니다. 홈에는 Person·Organization·WebSite·ProfilePage 구조화 데이터와 실제 사용자에게 보이는 전문 분야·FAQ 콘텐츠를 함께 제공합니다.

1. 왜 Cloudflare Workers 리버스 프록시인가?

외부 플랫폼이나 별도 호스팅 서비스에서 운영되는 웹사이트는 원본 주소가 그대로 노출되거나 페이지별 SEO 설정을 세밀하게 제어하기 어려운 경우가 있습니다. Cloudflare Worker를 앞단에 두면 다음 작업을 한곳에서 처리할 수 있습니다.

• 브랜드 공개 도메인으로 URL 통일
• 원본 서버 요청 전달과 리다이렉트 주소 재작성
• 페이지별 title·description·canonical 보강
• Open Graph·Twitter Card 메타데이터 제공
• Person·Organization·WebSite·WebPage JSON-LD 삽입
• robots.txt와 sitemap.xml 제공
• Google Analytics와 네이버 로그 분석 연결

즉, Worker는 단순한 프록시가 아니라 공개 URL 정책과 검색 최적화 정책을 실행하는 엣지 계층으로 동작합니다.

2. 전체 요청 흐름

1. 방문자가 www.allding.co.kr로 접속합니다.
2. Worker가 요청 URL의 호스트를 원본 서버 주소로 바꿉니다.
3. 프록시 관련 요청 헤더를 정리하고 Origin과 Referer를 원본에 맞춥니다.
4. 원본 응답이 HTML이면 URL을 공개 도메인으로 치환합니다.
5. title, description, canonical, 소셜 메타, JSON-LD를 삽입합니다.
6. 홈에는 AI 전문 분야 설명과 질문·답변 블록을 실제 본문으로 추가합니다.

const PUBLIC_DOMAIN = 'www.allding.co.kr';
const PUBLIC_ORIGIN = `https://${PUBLIC_DOMAIN}`;
const UPSTREAM_DOMAIN = 'seohangju-gd6k5mcu.manus.space';
const UPSTREAM_ORIGIN = `https://${UPSTREAM_DOMAIN}`;

공개 도메인과 원본 도메인을 상수로 분리하면 배포 환경이 바뀌어도 수정 범위를 최소화할 수 있습니다. 코드 전반에서 문자열을 직접 반복하지 않는 것이 운영 안정성에도 유리합니다.

3. 요청 전달: 메서드와 본문을 그대로 보존하기

리버스 프록시는 GET 페이지만 보여 주는 것으로 끝나지 않습니다. 폼 제출이나 API 호출을 지원하려면 POST, PUT, PATCH, DELETE 요청의 본문도 원본으로 전달해야 합니다.

const init = {
  method: request.method,
  headers,
  redirect: 'manual'
};

if (!['GET', 'HEAD'].includes(request.method)) {
  init.body = request.body;
}

return fetch(upstreamUrl.toString(), init);

redirect: 'manual'을 사용한 이유는 원본이 돌려주는 Location 헤더를 Worker가 확인하고 공개 도메인 주소로 바꾸기 위해서입니다. 자동 리다이렉트를 허용하면 방문자에게 원본 주소가 노출될 수 있습니다.

4. SEO 기본 요소: title, description, canonical

홈 제목은 이름과 핵심 전문 분야, 역할, 브랜드를 자연스러운 순서로 배치했습니다.

서항주 교수 | AI·인공지능·피지컬 AI 전문가·강사 | AllDing

description에는 AI·인공지능·생성형 AI·피지컬 AI뿐 아니라 기업·대학 교육, 특강, 강의, 컨설팅이라는 실제 서비스 범위를 담았습니다. 키워드를 무작정 반복하기보다 방문자가 페이지에서 확인할 수 있는 내용과 일치시키는 것이 중요합니다.

하위 페이지는 원본 title과 description을 우선 사용하되, 제목에 브랜드명이 없으면 | AllDing을 덧붙입니다. canonical과 hreflang은 현재 요청 경로를 기준으로 공개 도메인 URL을 생성합니다.

5. AEO 핵심: 검색어 나열이 아니라 엔티티와 답변 구조 만들기

AEO는 키워드를 많이 넣는 작업이 아닙니다. 검색엔진과 생성형 AI가 “이 페이지는 누구에 관한 것인지”, “무엇을 제공하는지”, “질문에 대한 답이 어디에 있는지”를 쉽게 파악하도록 만드는 작업입니다.

AllDing Worker는 하나의 @graph 안에 다음 엔티티를 연결합니다.

• Organization: AllDing 브랜드와 공식 URL
• Person: 서항주 교수의 이름, 직함, 전문 분야, 소속
• WebSite: 사이트 이름, 언어, 발행 주체
• ProfilePage 또는 WebPage: 현재 페이지와 핵심 인물·주제의 관계

const structuredData = {
  '@context': 'https://schema.org',
  '@graph': [
    { '@type': 'Organization', /* ... */ },
    { '@type': 'Person', /* ... */ },
    { '@type': 'WebSite', /* ... */ },
    { '@type': isHome ? 'ProfilePage' : 'WebPage', /* ... */ }
  ]
};

@id로 Person, Organization, WebSite, WebPage를 연결하면 서로 떨어진 데이터 조각이 아니라 하나의 일관된 지식 구조로 해석될 가능성이 높아집니다. 단, 직함·경력·소속·전문 분야는 실제 사실과 계속 일치하도록 관리해야 합니다.

6. 보이는 본문과 구조화 데이터의 내용 일치

JSON-LD에만 전문 분야를 넣고 화면에는 아무 설명이 없다면 사용자와 검색엔진 모두에게 불완전한 페이지가 됩니다. 그래서 홈 하단에는 다음 내용을 실제 HTML로 노출합니다.

• AI·인공지능 및 생성형 AI 실무 교육
• 피지컬 AI(Physical AI)의 개념과 산업 적용
• 기업 임직원·리더 대상 AI 교육과 특강
• 대학 대상 AI 특강과 강의
• AI 기반 디지털전환과 프로젝트관리

또한 “AI 전문가·교수·강사를 찾는 경우 어떤 교육을 받을 수 있나요?”, “피지컬 AI 관련 강의도 가능한가요?”와 같은 질문에 짧고 명확한 답을 제공합니다. 이것이 AEO에서 중요한 질문-답변 단위의 정보 구조입니다.

7. 기존 메타데이터 중복 방지

원본 HTML에 이미 title, description, canonical, Open Graph, JSON-LD가 있다면 새 태그를 무조건 덧붙여서는 안 됩니다. 값이 서로 다르면 검색엔진이 어느 정보를 기준으로 삼아야 할지 모호해질 수 있습니다.

이 구현은 기존 SEO 관련 meta·link·JSON-LD를 제거한 뒤 Worker가 계산한 값으로 다시 삽입합니다. 다만 정규식 기반 HTML 수정은 복잡한 마크업에서 예외가 생길 수 있으므로, 실제 배포 환경에서는 다양한 페이지 템플릿을 테스트하고 가능하면 HTMLRewriter 사용도 검토할 수 있습니다.

8. robots.txt와 sitemap.xml 자동 제공

/robots.txt 요청에는 일반 크롤러, 네이버 Yeti, Googlebot에 대한 접근 허용과 사이트맵 주소를 반환합니다.

User-agent: *
Allow: /

User-agent: Yeti
Allow: /

User-agent: Googlebot
Allow: /

Sitemap: https://www.allding.co.kr/sitemap.xml

사이트맵은 세 단계로 처리합니다.

1. 원본 서버의 sitemap.xml이 유효하면 공개 도메인으로 URL을 바꿔 사용합니다.
2. 원본 사이트맵이 없으면 내부 링크를 제한적으로 탐색해 실제 2xx HTML 페이지만 수집합니다.
3. 크롤링도 실패하면 최소한 홈 URL을 포함한 사이트맵을 반환합니다.

탐색 개수, 동시 요청 수, 타임아웃, 캐시 시간을 제한해 Worker가 무한 크롤러처럼 동작하지 않도록 한 점도 중요합니다.

9. SPA 환경의 fetch와 XMLHttpRequest 보완

HTML 안의 URL만 바꿔도 SPA가 실행 중 원본 주소로 API를 요청할 수 있습니다. 이를 보완하기 위해 브라우저의 fetch와 XMLHttpRequest.open을 감싸 공개 도메인 요청을 원본 주소로 변환합니다.

이 방식은 빠른 호환성 보완에 유용하지만 전역 API를 패치하므로 로그인·결제·파일 업로드·스트리밍 요청 등을 별도로 시험해야 합니다. 장기적으로는 애플리케이션의 API base URL을 환경 변수로 관리하는 방식이 더 명확할 수 있습니다.

10. 운영 전에 확인할 보안 체크리스트

• CORS: 모든 출처 허용이 정말 필요한지 확인합니다.
• 보안 헤더: CSP와 X-Frame-Options를 제거해야 하는 이유를 검토하고 최소 범위만 조정합니다.
• Origin·Referer: 원본 애플리케이션의 CSRF 정책과 충돌하지 않는지 시험합니다.
• 캐시: 개인화 페이지나 인증 응답이 공유 캐시에 저장되지 않도록 합니다.
• 구조화 데이터: 실제 화면 내용과 직함·서비스·소속 정보가 일치하는지 정기적으로 점검합니다.
• 오류 처리: 원본 장애 시 502 응답과 로그에 민감한 정보가 노출되지 않는지 확인합니다.

11. 자주 묻는 질문

Cloudflare Workers만 적용하면 검색 순위가 바로 오르나요?

아닙니다. Worker는 검색엔진이 페이지를 수집하고 이해하기 좋은 기술적 기반을 제공합니다. 실제 순위에는 콘텐츠 품질, 전문성, 사용자 경험, 사이트 신뢰도, 내부·외부 링크 등 다양한 요소가 함께 작용합니다.

메타 keywords도 추가해야 하나요?

핵심은 meta keywords가 아니라 실제 본문, 명확한 페이지 제목과 설명, 내부 링크, 구조화 데이터의 일관성입니다. 전문 분야 목록은 본문 주제 설계와 엔티티 설명에 활용하는 편이 좋습니다.

피지컬 AI처럼 새로운 주제는 AEO를 어떻게 적용하나요?

용어 정의, 산업 적용 사례, 대상 독자, 교육에서 다루는 범위를 구체적인 질문과 답으로 구성합니다. “피지컬 AI란 무엇인가?”, “기업과 대학에서 어떻게 활용할 수 있는가?”처럼 사용자가 실제로 묻는 문장에 직접 답하는 콘텐츠가 도움이 됩니다.

원본 사이트가 바뀌면 Worker도 수정해야 하나요?

원본 도메인, 페이지 구조, API 경로, 보안 정책이 바뀌면 수정이 필요할 수 있습니다. 특히 HTML 삽입 위치와 URL 치환 규칙, 인증 요청은 배포 후에도 모니터링해야 합니다.

마무리

AllDing의 Cloudflare Worker 구성은 리버스 프록시, 공개 도메인 정규화, SEO 메타데이터, JSON-LD 엔티티 연결, AEO용 가시 콘텐츠, robots.txt와 sitemap.xml을 하나의 엣지 로직으로 통합한 사례입니다.

가장 중요한 원칙은 기술적으로 삽입한 정보와 사용자가 실제로 보는 콘텐츠를 일치시키는 것입니다. 검색엔진만을 위한 숨은 최적화가 아니라, 방문자가 서항주 교수의 AI·생성형 AI·피지컬 AI 교육과 강의 분야를 빠르게 이해하도록 만드는 것이 SEO와 AEO의 공통 출발점입니다.

AllDing 공식 사이트 방문하기

서항주 교수 | AI·인공지능·피지컬 AI 전문가·강사 | AllDing