기술적 SEO: 크롤링, 색인, Core Web Vitals, 서버 설정

기술적 SEO(Technical SEO)는 검색엔진과 AI 크롤러가 사이트를 발견하고, 크롤링하고, 렌더링하고, 색인할 수 있도록 서버·코드·설정을 정비하는 모든 작업입니다. 콘텐츠가 아무리 좋아도 크롤러가 접근하지 못하거나 페이지가 느리고 불안정하면 검색 결과와 AI 답변 모두에서 불리해집니다. 이 파트는 2026년 9월 기준 공식 문서를 바탕으로 개발자와 마케터가 함께 쓸 수 있는 실무 체크리스트를 정리합니다.

5-A. 크롤링과 색인: 검색엔진 접근성 확보

검색엔진 접근성 확보란 크롤러가 중요한 URL을 빠짐없이 찾고 불필요한 URL에 자원을 낭비하지 않도록 robots.txt, XML 사이트맵, 리다이렉트, 내부 링크를 정리하는 일입니다. 구글·빙·네이버 모두 기본 원리는 같으며, 네이버의 검색 로봇 이름은 Yeti입니다. 이 섹션의 설정은 AI 검색에도 그대로 영향을 줍니다. AI 답변의 상당수가 검색 색인에서 후보 문서를 찾기 때문입니다.

5.1 robots.txt 설정 기본

robots.txt는 사이트 루트(https://example.com/robots.txt)에 두는 텍스트 파일로, 크롤러에게 어느 경로를 크롤링해도 되는지 알려 주는 표준 규약(RFC 9309)입니다. 규칙은 User-agent별로 묶고, Disallow와 Allow로 경로를 지정합니다. 크롤러는 자신에게 해당하는 가장 구체적인 그룹 하나만 따르므로, 특정 봇 그룹을 만들면 User-agent: * 그룹의 규칙은 그 봇에 적용되지 않는다는 점에 주의하세요.

기본 문법

User-agent: *          # 모든 크롤러에 적용
Disallow: /admin/      # /admin/ 경로 크롤링 차단
Disallow: /private/    # /private/ 경로 크롤링 차단
Allow: /               # 그 외 모든 경로 허용

Sitemap: https://example.com/sitemap.xml   # 사이트맵 위치 안내

자주 차단하는 경로

User-agent: *
Disallow: /admin/
Disallow: /wp-admin/         # WordPress 관리자
Allow: /wp-admin/admin-ajax.php
Disallow: /cart/             # 장바구니
Disallow: /checkout/         # 결제
Disallow: /my-account/       # 회원 마이페이지
Disallow: /search/           # 내부 검색 결과
Disallow: /?s=               # WordPress 검색 파라미터
Allow: /

CSS와 JavaScript 파일은 차단하지 마세요. 구글은 페이지를 브라우저처럼 렌더링해 평가하므로, 렌더링에 필요한 리소스가 막히면 페이지 내용과 모바일 적합성을 잘못 판단할 수 있습니다.

robots.txt의 치명적인 실수

가장 흔하고 치명적인 실수는 중요한 페이지를 실수로 차단하는 것입니다. 스테이징 서버의 Disallow: /가 운영 서버에 그대로 배포되면 사이트 전체가 검색에서 사라질 수 있으므로, 배포 파이프라인에서 robots.txt를 자동 점검하는 것이 안전합니다.

• noindex 페이지를 robots.txt로 함께 차단: 크롤러가 페이지를 읽지 못하면 noindex 지시도 보지 못해, 외부 링크가 있는 URL이 색인에 남을 수 있습니다. 색인에서 빼려면 크롤링은 허용하고 noindex를 사용하세요.
• robots.txt 응답 오류: 네이버 서치어드바이저는 HTML로 응답하는 robots.txt를 ‘robots.txt 없음’으로, 5xx 서버 오류 응답을 ‘전체 수집 금지’로 처리할 수 있다고 안내합니다. robots.txt는 항상 200 상태 코드와 일반 텍스트로 응답하게 하세요.
• 보안 목적의 사용: robots.txt는 누구나 읽을 수 있는 공개 파일이며 강제력이 없습니다. 관리자 경로나 비공개 자료는 로그인 인증으로 보호해야 합니다.

GPTBot, ClaudeBot, Google-Extended 같은 AI 크롤러별 설정과 트레이드오프는 5-B. AI 크롤러와 robots.txt에서 자세히 다룹니다.

5.2 XML 사이트맵 전략적 활용

XML 사이트맵은 색인되기를 원하는 정식(canonical) URL 목록을 검색엔진에 전달하는 파일입니다. 사이트맵은 발견을 돕는 힌트일 뿐 색인을 보장하지는 않지만, 페이지 수가 많거나 새 페이지가 자주 생기거나 내부 링크가 약한 사이트에서는 효과가 큽니다.

기본 사이트맵 구조

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/seo-guide/</loc>
    <lastmod>2026-09-28</lastmod>
  </url>
</urlset>

구글은 <priority>와 <changefreq> 값을 사용하지 않고, <lastmod>는 일관되게 정확할 때만 참고합니다. 오타 수정이나 푸터 변경이 아니라 본문이 실제로 바뀌었을 때만 lastmod를 갱신하세요.

사이트맵 유형

• 사이트맵 인덱스(sitemap_index.xml): 여러 사이트맵을 묶는 인덱스 파일입니다. 사이트맵 파일 하나에는 URL 50,000개, 비압축 기준 50MB까지 담을 수 있으므로 이를 넘거나 유형별로 나눌 때 사용합니다.
• 게시물·페이지 사이트맵: 블로그 글, 일반 페이지, 상품 등 콘텐츠 유형별로 나누면 Search Console에서 유형별 색인 현황을 따로 확인할 수 있습니다.
• 이미지 사이트맵: 이미지 URL을 함께 전달해 이미지 검색 노출을 돕습니다.
• 동영상 사이트맵: 동영상 콘텐츠의 위치와 메타데이터를 전달합니다.
• 뉴스 사이트맵: 뉴스 사이트 전용이며, 최근 2일 이내에 게시한 기사만 포함합니다.

사이트맵에 포함하지 말아야 할 페이지

사이트맵에는 200 상태 코드로 응답하는, 색인을 원하는 정식 URL만 넣어야 합니다.

• noindex가 설정된 페이지
• 리다이렉트(301/302)되는 URL
• 404·410 오류 페이지
• canonical이 다른 URL을 가리키는 중복 페이지
• robots.txt로 차단된 URL
• 로그인이 필요한 페이지

사이트맵 제출과 모니터링

1. robots.txt에 위치 명시: Sitemap: 줄은 구글·빙·네이버를 포함한 대부분의 검색엔진이 읽습니다.
2. Google Search Console: ‘Sitemaps(사이트맵)’ 보고서에 사이트맵 URL을 제출하고, 상태가 ‘성공’인지와 발견된 URL 수를 확인합니다.
3. Bing Webmaster Tools와 네이버 서치어드바이저: 각 도구의 사이트맵 제출 메뉴에서도 등록해 둡니다.
4. 정기 점검: 제출한 URL 수와 ‘페이지 색인 생성’ 보고서의 색인된 페이지 수가 크게 다르면 품질·중복·크롤링 문제의 신호입니다.

구글의 사이트맵 핑(ping) 기능은 종료되었습니다. 구글에는 Search Console 제출, robots.txt의 Sitemap 줄, 정확한 lastmod면 충분하고, 빙·네이버에 변경 사항을 빠르게 알리려면 다음 절의 IndexNow를 함께 사용하세요.

5.3 IndexNow: 빙·네이버에 변경 사항 즉시 알리기

IndexNow는 URL이 새로 생기거나 바뀌거나 삭제됐을 때 웹사이트가 검색엔진에 직접 알리는 오픈 프로토콜입니다. 네이버는 2023년 7월 25일부터 IndexNow를 지원하며, 한 엔진에 보낸 알림은 IndexNow에 참여하는 다른 엔진과 공유됩니다. IndexNow 공식 엔진 목록에는 네이버와 함께 빙(Bing), 얀덱스(Yandex), Seznam, Yep 등이 올라 있으며 구글은 포함되어 있지 않습니다.

1. 키 만들기: 임의의 키 문자열을 생성합니다. 네이버에 IndexNow를 쓰는 데 서치어드바이저 사이트 등록은 필요하지 않습니다.
2. 키 파일 호스팅: 키 값을 담은 텍스트 파일을 사이트 루트(예: https://example.com/{키}.txt)에 올려 소유권을 증명합니다.
3. 변경 URL 전송: 페이지를 발행·수정·삭제할 때 아래처럼 URL 목록을 POST로 보냅니다.

POST https://searchadvisor.naver.com/indexnow
Content-Type: application/json; charset=utf-8

{
  "host": "example.com",
  "key": "여기에-생성한-키",
  "keyLocation": "https://example.com/여기에-생성한-키.txt",
  "urlList": [
    "https://example.com/guide/new-post",
    "https://example.com/products/updated-item"
  ]
}

IndexNow는 크롤링을 요청하는 신호일 뿐 색인을 보장하지 않습니다. 실제로 바뀐 URL만 보내고, 많은 CMS 플러그인과 CDN이 제공하는 자동 전송 기능을 쓰는 경우 중복 전송이 없는지 확인하세요.

5.4 크롤링 예산(Crawl Budget) 최적화

크롤링 예산은 검색엔진이 한 사이트에서 일정 기간 동안 크롤링할 수 있고, 또 크롤링하고 싶어 하는 URL의 양입니다. 구글은 이를 서버가 감당할 수 있는 ‘크롤링 용량 한도’와 URL의 인기·최신성에 따른 ‘크롤링 수요’의 조합으로 설명합니다. 페이지가 매우 많거나 콘텐츠가 매우 자주 바뀌는 대형 사이트가 아니라면 크롤링 예산보다 사이트맵 관리와 색인 현황 점검이 더 중요합니다.

크롤링 예산이 낭비되는 원인

• 파라미터 URL 과다: 필터, 정렬, 추적 파라미터 조합으로 수천 개의 중복 URL이 생성됩니다. 쇼핑몰의 다중 필터(패싯 내비게이션)가 대표적입니다.
• 끝없는 URL 공간: 무한히 이어지는 캘린더, 검색 결과, 페이지 목록
• 세션 ID URL: ?sessionid=abc123 형태의 URL
• 저품질·중복 페이지 과다: 내용이 거의 없는 페이지, 빈 카테고리 페이지, 소프트 404
• 리다이렉트 체인과 오류 응답: 여러 번 거치는 리다이렉트, 잦은 5xx 오류
• 느린 서버 응답: 응답이 느리거나 500·503·429 응답이 늘면 구글봇은 서버 보호를 위해 크롤링 속도를 낮춥니다.

크롤링 예산 최적화 방법

• 색인할 필요가 없는 파라미터·필터 URL 패턴은 robots.txt로 크롤링을 막습니다. noindex는 페이지를 읽어야 적용되므로 크롤링을 줄여 주지 않습니다.
• 중복 URL은 canonical로 대표 URL을 지정하고, 내부 링크는 항상 대표 URL을 가리키게 합니다.
• 저품질 페이지는 개선·통합하거나 삭제합니다.
• 서버 응답 속도(TTFB)를 개선하고 5xx 오류를 줄입니다.
• 중요한 페이지는 홈이나 허브 페이지에서 몇 번의 클릭 안에 닿도록 내부 링크 구조를 정리하고, 내부 링크가 하나도 없는 고아 페이지(orphan page)를 없앱니다.
• Google Search Console의 ‘설정 → 크롤링 통계’ 보고서와 서버 로그로 봇이 실제로 어떤 URL에 시간을 쓰는지 확인합니다.

5.5 404 오류와 301 리다이렉트 전략

페이지를 옮겼다면 301 리다이렉트로 새 주소를 알려 주고, 대체할 페이지가 없는 삭제라면 404 또는 410 상태 코드를 그대로 반환하는 것이 원칙입니다. 404 오류 자체는 사이트 전체 순위에 불이익을 주지 않습니다. 다만 외부 링크를 받던 URL이 404가 되면 그 링크의 가치가 사라지므로, 링크가 있는 URL부터 우선 처리합니다.

404 오류 관리

확인 위치: Google Search Console → ‘페이지 색인 생성(Page indexing)’ 보고서 → ‘찾을 수 없음(404)’ 사유. Ahrefs, Semrush, Screaming Frog 같은 도구로 외부 링크를 받는 404 URL을 찾을 수도 있습니다.

1. 콘텐츠가 이동되었다면 → 새 URL로 301 리다이렉트
2. 같은 목적을 가진 대체 콘텐츠가 있다면 → 가장 관련성 높은 페이지로 301 리다이렉트
3. 콘텐츠가 완전히 사라지고 대체 페이지가 없다면 → 404 또는 410 반환. 삭제된 URL을 모두 홈페이지로 보내면 구글이 이를 소프트 404로 처리할 수 있습니다.

404 페이지는 검색창과 주요 메뉴 링크를 담아 사용자가 길을 잃지 않게 만들되, 반드시 404 상태 코드로 응답해야 합니다. ‘페이지를 찾을 수 없습니다’라는 화면을 200 상태 코드로 보내면 소프트 404가 됩니다.

301과 302의 차이

구글은 두 방식 모두에서 링크 신호를 넘겨주지만, 어떤 URL을 색인에 남길지 판단할 때 차이가 납니다. 영구적인 변경에는 301을 쓰고, 리다이렉트가 여러 번 이어지는 체인을 만들지 말고, 내부 링크는 최종 URL로 직접 수정하세요.

Nginx 301 리다이렉트 설정 예시:

# 특정 URL 리다이렉트
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# 디렉토리 이동 (하위 경로를 그대로 유지)
location ^~ /old-category/ {
    rewrite ^/old-category/(.*)$ https://example.com/new-category/$1 permanent;
}

# HTTP → HTTPS, www → non-www를 한 번에 처리 (리다이렉트 체인 방지)
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    # ssl_certificate, ssl_certificate_key 설정 생략
    return 301 https://example.com$request_uri;
}

5.6 페이지네이션과 무한 스크롤 처리

페이지네이션은 각 페이지에 고유한 URL을 주고, 페이지끼리 일반 <a href> 링크로 연결하는 것이 기본입니다. 구글은 더 이상 rel="prev"/rel="next"를 색인 신호로 사용하지 않으므로, 링크 구조 자체가 크롤러에게 목록의 뒷부분을 알려 주는 유일한 경로입니다.

페이지네이션 처리 방법

• 페이지별 고유 URL: /category?page=2처럼 각 페이지가 독립된 URL을 갖게 합니다. URL 조각(#page=2)은 크롤러가 별도 페이지로 보지 않습니다.
• 자기 참조 canonical: 2페이지 이후의 canonical을 1페이지로 지정하지 마세요. 뒤쪽 페이지에만 있는 상품이나 글이 발견되지 않을 수 있습니다.
• 전체 보기 페이지: 모든 항목을 한 페이지에 보여주는 ‘전체 보기’ 페이지를 대표 URL로 삼는 방법도 있지만, 페이지가 무거워져 성능이 나빠지지 않는지 확인하세요.
• 필터·정렬 URL: 정렬 순서만 다른 URL은 색인할 가치가 낮으므로 canonical이나 robots.txt로 정리합니다.

무한 스크롤(Infinite Scroll) 처리

구글봇은 페이지를 스크롤하거나 ‘더 보기’ 버튼을 클릭하지 않습니다. 스크롤해야만 불러오는 항목은 첫 화면만 크롤링될 수 있습니다.

• 무한 스크롤 뒤에 링크로 연결된 페이지네이션 URL을 함께 제공합니다.
• 사용자가 스크롤할 때 History API로 주소창의 URL을 해당 페이지 URL로 바꿔 주면 공유와 재방문도 자연스러워집니다.
• 각 항목에 고유 URL이 있다면 사이트맵에 모두 포함합니다.

5-B. AI 크롤러와 robots.txt

AI 크롤러 관리란 모델 학습(training)용 크롤러, AI 검색 색인용 크롤러, 사용자 요청형 페처(fetcher)를 구분해 robots.txt로 각각 허용하거나 차단하는 일입니다. 같은 회사라도 용도별로 토큰이 나뉘어 있으므로, 학습은 거부하면서 AI 검색 답변에는 인용되는 설정이 가능합니다. 아래 표는 2026년 9월 각 회사의 공식 문서를 기준으로 정리했습니다.

5.7 주요 AI 크롤러 토큰 한눈에 보기

robots.txt에서 AI 크롤러를 제어할 때는 회사 이름이 아니라 공식 문서에 적힌 User-agent 토큰을 정확히 써야 합니다. 예전 글에 자주 보이는 anthropic-ai는 Anthropic의 현재 크롤러 문서에 없는 토큰이며, Anthropic은 ClaudeBot, Claude-User, Claude-SearchBot 세 가지를 안내합니다.

빙과 Copilot에서의 AI 활용만 제한하려면 robots.txt가 아니라 메타 태그를 씁니다. 빙(2023-09-22)에 따르면 NOCACHE가 붙은 콘텐츠는 AI 답변에 URL·제목·스니펫만 표시되고, NOARCHIVE가 붙은 콘텐츠는 AI 답변에 포함되지 않으며, 두 경우 모두 일반 검색 결과에는 계속 나타납니다.

5.8 목적별 robots.txt 예시와 트레이드오프

대부분의 기업 사이트에 무난한 기본값은 ‘검색과 AI 답변에는 노출하고, 모델 학습에는 사용을 거부하는’ 설정입니다. 검색·답변용 토큰(Googlebot, bingbot, Yeti, OAI-SearchBot, Claude-SearchBot, PerplexityBot)은 허용하고, 학습용 토큰(GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, meta-externalagent)만 차단합니다.

# ① 모든 크롤러 기본 규칙 (검색엔진 포함)
User-agent: *
Disallow: /admin/
Disallow: /cart/

# ② AI 모델 학습용 토큰은 전체 차단
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: meta-externalagent
Disallow: /

# ③ AI 검색·답변용 크롤러는 허용
#    (전용 그룹이 생기면 ①의 규칙이 적용되지 않으므로 차단 경로를 다시 적습니다)
User-agent: OAI-SearchBot
User-agent: Claude-SearchBot
User-agent: PerplexityBot
Disallow: /admin/
Disallow: /cart/

Sitemap: https://example.com/sitemap.xml

설정별 트레이드오프

어떤 전략이든 robots.txt는 ‘요청’일 뿐 강제 수단이 아닙니다. 서버 로그에서 User-agent 문자열만 믿지 말고, 각 회사가 공식 문서로 안내하는 방법(공개 IP 대역, 역방향 DNS 확인 등)으로 진짜 봇인지 확인한 뒤 차단·허용 정책을 적용하세요. AI 답변에 인용되기 좋은 콘텐츠 설계는 PART 04. AEO·GEO 실전에서 다룹니다.

5.9 Cloudflare의 AI 크롤러 설정 점검

Cloudflare를 쓰는 사이트는 robots.txt와 별개로 Cloudflare 대시보드의 봇·AI 크롤러 설정이 실제 접근 허용 여부를 좌우하므로, 두 가지를 함께 점검해야 합니다. 특히 2026년 9월 15일 변경 이후에는 설정 하나로 검색엔진까지 차단될 수 있습니다.

Cloudflare 설정 변화 타임라인

Content-Signal 줄의 의미

Content Signals Policy는 robots.txt에 콘텐츠 사용 선호를 기계가 읽을 수 있는 형태로 적는 방식입니다. search는 검색 색인 구축(AI 요약 제외), ai-input은 RAG·그라운딩 등 실시간 AI 답변에 입력으로 쓰는 것, ai-train은 모델 학습·파인튜닝을 뜻합니다.

# 검색 색인과 AI 답변 입력은 허용, 모델 학습은 거부
User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

이 신호는 CC0 라이선스로 공개된 ‘선호 표시’일 뿐 기술적인 강제 수단이 아니며, 표준 robots.txt 지시어도 아닙니다. 어떤 크롤러가 이 신호를 존중하는지는 각 회사의 발표를 확인해야 합니다.

Cloudflare 사용자 점검 순서

1. 대시보드의 봇·AI 크롤러 설정에서 ‘Block’이 선택돼 있는지 확인하고, 검색 노출이 필요하면 ‘Disallow AI Training’ 등으로 바꿉니다.
2. 브라우저로 https://내도메인/robots.txt를 열어 실제로 응답되는 내용을 확인합니다.
3. Google Search Console의 크롤링 통계, Bing Webmaster Tools, 네이버 서치어드바이저에서 크롤링 오류가 늘지 않았는지 봅니다.
4. Cloudflare 보안 이벤트와 서버 로그에서 Googlebot, bingbot, Yeti, OAI-SearchBot 요청이 403으로 차단되고 있지 않은지 확인합니다.

5.10 구글 AI 개요·AI 모드 노출 제어: 스니펫 제어와 Search Console

구글의 AI 개요와 AI 모드는 별도 크롤러가 아니라 Googlebot이 수집한 검색 색인을 사용하므로, 노출 범위는 스니펫 제어(nosnippet, data-nosnippet, max-snippet, noindex)와 Search Console의 ‘검색 생성형 AI’ 설정으로 조절합니다. Google Search Central은 AI 기능에 노출되는 데 별도의 요구 사항이 없고, 일반 검색과 같은 기술 조건(크롤링 허용, 색인, 스니펫 표시 가능)을 충족하면 된다고 설명합니다.

<!-- 페이지 전체: 스니펫과 AI 기능 입력 제한 -->
<meta name="robots" content="nosnippet">

<!-- 스니펫 길이를 최대 160자로 제한 -->
<meta name="robots" content="max-snippet:160">

<!-- 특정 영역만 제외 -->
<p>검색과 AI 답변에 보여도 되는 요약 문단</p>
<div data-nosnippet>회원 전용 가격표, 내부 정책 등</div>

# PDF 등 HTML이 아닌 파일은 HTTP 헤더로 지정
X-Robots-Tag: nosnippet

Search Console ‘검색 생성형 AI’ 설정

구글(2026-06-03 발표, 08-31 업데이트)은 Search Console의 설정 → 검색 생성형 AI(Search generative AI) 메뉴에서 사이트 전체를 AI 개요, AI 모드, Discover의 생성형 AI 기능에 포함하거나 제외할 수 있게 했고, 2026년 8월 31일 전 세계 모든 사이트로 확대했습니다. 도움말에 따르면 변경은 약 1~2일 뒤 반영되고, 제외한 사이트는 해당 기능에서 트래픽과 노출을 받지 않습니다. 이 설정은 검색의 다른 영역에서 순위나 포함 여부를 정하는 신호로 쓰이지 않으며, AI 학습 거부는 이 설정이 아니라 Google-Extended로 해야 합니다.

• 언제 쓰나: 유료 콘텐츠나 라이선스 문제로 AI 요약 노출을 원하지 않을 때 사이트 단위로 씁니다. 일부 페이지나 문단만 제한하려면 위의 스니펫 제어가 더 정밀합니다.
• 주의: nosnippet은 일반 검색 결과의 설명 문구까지 없애므로 클릭률이 떨어질 수 있습니다. 제외 전후로 트래픽 변화를 반드시 비교하세요.
• 측정: 같은 날 모든 사이트로 확대된 ‘생성형 AI 실적’ 보고서에서 AI 개요·AI 모드 노출수(클릭 수는 제공되지 않음)를 확인할 수 있습니다. 측정 방법은 PART 07. SEO·GEO 성과 측정에서 다룹니다.

애플도 nosnippet을 존중합니다. Apple에 따르면 nosnippet이 적용된 콘텐츠는 Siri와 검색의 일반 지식 AI 답변에 추가 맥락으로 쓰이지 않습니다.

5.11 핵심 콘텐츠는 서버에서 렌더링된 HTML에

검색엔진과 AI 크롤러가 핵심 내용을 확실히 읽게 하려면 본문, 제목, 가격, 핵심 답변 문단 같은 중요한 콘텐츠를 JavaScript 실행 없이도 보이는 서버 렌더링 HTML에 담는 것이 가장 안전합니다. 구글은 JavaScript를 렌더링하지만 렌더링 단계가 크롤링보다 늦게 처리될 수 있고, AI 회사들은 자사 크롤러가 JavaScript를 어디까지 실행하는지 자세히 공개하지 않는 경우가 많습니다. 이는 통계가 아니라 불확실성을 줄이기 위한 실무 원칙입니다.

• 브라우저의 ‘페이지 소스 보기’나 아래 명령으로, JavaScript 실행 전 원본 HTML에 핵심 문장이 들어 있는지 확인합니다.
• 탭·아코디언 안의 내용도 HTML에 미리 들어 있게 하고, 클릭해야 서버에서 불러오는 방식은 피합니다.
• 제목, 메타 설명, canonical, 구조화 데이터는 서버 응답 단계에서 완성해 둡니다.
• 상품 가격·재고처럼 자주 바뀌는 정보도 첫 HTML 응답에 포함합니다.

# JavaScript를 실행하지 않은 원본 HTML에 핵심 문장이 있는지 확인
curl -s https://example.com/pricing | grep "월 요금"

렌더링 방식별 비교(SSR, SSG, CSR)는 5.24에서 다룹니다.

5-C. 페이지 성능 극대화 (Core Web Vitals)

Core Web Vitals는 구글이 실제 사용자 경험을 측정하기 위해 정한 세 가지 지표(LCP, INP, CLS)이며, ‘좋음’ 기준은 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하입니다. 구글의 순위 시스템은 Core Web Vitals를 페이지 경험의 일부로 반영하지만, 좋은 점수가 상위 노출을 보장하지는 않습니다. 검색 의도에 맞는 유용한 콘텐츠가 먼저이고, 성능은 비슷한 품질의 페이지 사이에서 차이를 만들며 사용자 이탈과 전환율에 직접 영향을 줍니다.

5.12 Core Web Vitals 3대 지표 완벽 분석

세 지표는 모두 실제 방문자의 페이지 로드 중 75번째 백분위수 값으로, 모바일과 데스크톱을 따로 평가합니다. 즉 방문의 75% 이상이 ‘좋음’ 기준을 충족해야 해당 페이지가 ‘좋음’으로 분류됩니다. 반응성 지표는 2024년 3월 12일 INP가 FID를 대체했고, Chrome 도구들은 2024년 9월 9일 이후 FID 지원을 중단했습니다.

LCP 개선 방법

• LCP 요소가 되는 히어로 이미지는 loading="lazy"로 지연 로딩하지 말고 fetchpriority="high"를 지정합니다.
• 이미지를 AVIF나 WebP로 변환하고 화면에 필요한 크기로 제공합니다.
• CSS 배경 이미지처럼 브라우저가 늦게 발견하는 LCP 리소스는 <link rel="preload">로 미리 알립니다.
• TTFB(첫 바이트까지의 시간)를 줄입니다. 서버 캐시와 CDN이 가장 효과적입니다.
• 서버 사이드 렌더링(SSR)이나 정적 생성(SSG)으로 첫 HTML에 콘텐츠를 담습니다.

<!-- LCP 히어로 이미지: 지연 로딩 금지, 우선순위 높임, 크기 명시 -->
<img src="/img/hero.avif" width="1200" height="630"
     alt="서비스 대표 이미지" fetchpriority="high">

INP 개선 방법

• 메인 스레드를 50ms 이상 점유하는 긴 작업(Long Task)을 잘게 나누고, 중간에 메인 스레드를 양보합니다.
• 무거운 JavaScript 실행과 불필요한 서드파티 스크립트를 줄입니다.
• React 등 프레임워크에서 불필요한 재렌더링을 최소화합니다.
• 무거운 계산은 Web Worker로 옮깁니다.
• 클릭 직후에는 로딩 표시 같은 시각적 피드백을 먼저 그리고, 무거운 처리는 그다음에 실행합니다.

CLS 개선 방법

• 모든 이미지와 동영상에 width·height 속성이나 CSS aspect-ratio를 지정합니다.
• 광고, 임베드, 배너가 들어갈 공간을 미리 확보합니다.
• 웹폰트 교체로 텍스트가 밀리지 않도록 font-display를 설정하고, 대체 폰트와 크기 차이가 작은 폰트를 고릅니다.
• 이미 보이는 콘텐츠 위에 요소를 동적으로 끼워 넣지 않습니다.
• 애니메이션은 레이아웃을 바꾸는 속성 대신 transform을 사용합니다.

5.13 PageSpeed Insights·Search Console·GTmetrix 활용법

성능 측정은 실제 사용자 데이터(필드 데이터)로 문제를 확인하고, 실험실 데이터(랩 데이터)로 원인을 찾는 순서로 진행합니다. 순위와 사용자 경험에 반영되는 것은 필드 데이터이고, 랩 데이터는 개발 중 원인 분석과 회귀 방지에 씁니다.

Google PageSpeed Insights (PSI)

pagespeed.web.dev에 URL을 입력하면 두 종류의 데이터를 보여 줍니다.

• 필드 데이터(실제 사용자 데이터): CrUX(Chrome User Experience Report)의 최근 28일 실제 Chrome 사용자 데이터입니다. 방문자가 적은 페이지는 데이터가 없거나 사이트 전체(origin) 값만 표시됩니다.
• 랩 데이터(시뮬레이션 데이터): Lighthouse로 한 번 측정한 결과입니다. 사용자의 실제 상호작용이 없으므로 INP 대신 TBT(Total Blocking Time)를 참고 지표로 봅니다.

필드 데이터가 ‘나쁨’이면 그 지표가 최우선 개선 대상입니다. 트래픽이 적어 필드 데이터가 없다면 web-vitals JavaScript 라이브러리로 직접 실사용자 데이터를 수집해 GA4 등으로 보내는 방법을 쓸 수 있습니다.

Search Console의 Core Web Vitals 보고서

Search Console의 ‘Core Web Vitals’ 보고서는 같은 CrUX 필드 데이터를 바탕으로, 비슷한 페이지를 URL 그룹으로 묶어 ‘나쁨·개선 필요·좋음’ 상태를 보여 줍니다. 템플릿 단위의 문제를 찾기에 좋으며, 수정 후 ‘수정 결과 확인’을 요청하면 28일 동안 추적합니다.

GTmetrix

gtmetrix.com은 Lighthouse 기반 측정과 함께 테스트 지역 선택, 워터폴 차트, 측정 기록 비교 기능을 제공합니다.

워터폴 차트 활용법:

• 가장 긴 막대를 가진 리소스를 확인합니다. 그 리소스가 병목 지점일 가능성이 큽니다.
• 첫 요청(HTML)의 대기 시간이 길면 서버·캐시 설정 문제입니다.
• CSS·JS 파일이 렌더링을 막고 있는지 확인합니다.

5.14 WebPageTest·Lighthouse 심층 분석

WebPageTest

webpagetest.org는 실제 브라우저와 네트워크 조건으로 로딩 과정을 자세히 분석하는 도구입니다.

• 필름스트립 보기(Filmstrip View): 로딩 과정을 일정 간격의 스크린샷으로 보여 줘, 어느 시점에 콘텐츠가 나타나는지 직관적으로 확인할 수 있습니다.
• 커넥션 보기(Connection View): 각 리소스의 DNS, TCP, TLS 연결과 응답 시간을 상세히 표시합니다.
• 재방문 보기(Repeat View): 두 번째 방문에서 캐시가 제대로 작동하는지 확인합니다.

Chrome DevTools Lighthouse

Chrome 개발자 도구(F12)의 Lighthouse 탭이나 명령줄로 바로 측정할 수 있어, 로컬 개발 환경에서 빠르게 점검할 때 유용합니다. 배포 파이프라인에 Lighthouse CI를 넣으면 성능이 나빠지는 변경을 배포 전에 잡아낼 수 있습니다.

# CLI로 Lighthouse 실행 (모바일 기준 기본값)
npx lighthouse https://example.com --output html --output-path ./report.html

5.15 이미지 전송 효율화 전략

이미지 최적화의 핵심은 차세대 포맷(AVIF·WebP)으로 압축하고, 화면 크기에 맞는 해상도만 보내고, 화면 밖 이미지는 나중에 불러오는 것입니다. 이미지는 대부분의 페이지에서 전송량이 가장 큰 리소스 중 하나이고 LCP 요소가 되는 경우가 많아, 개선 효과가 크게 나타나는 영역입니다.

이미지 압축 파이프라인

빌드 단계 압축(권장): 업로드나 빌드 시점에 한 번 변환해 두면 요청마다 처리할 필요가 없습니다.

// 설치: npm install sharp
import sharp from 'sharp';

// WebP와 AVIF를 함께 생성
await sharp('input.jpg').resize({ width: 1200 }).webp({ quality: 80 }).toFile('output.webp');
await sharp('input.jpg').resize({ width: 1200 }).avif({ quality: 50 }).toFile('output.avif');

이미지 CDN을 통한 실시간 변환:

Cloudflare Images, Imgix, Cloudinary 같은 이미지 CDN을 활용하면 URL 파라미터만으로 리사이징, 포맷 변환, 압축을 처리할 수 있습니다.

# Cloudflare Images 예시
https://example.com/cdn-cgi/image/width=800,format=webp/images/photo.jpg

반응형 이미지(Responsive Images)

<img
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  src="image-800.webp"
  alt="설명"
  loading="lazy"
/>

이렇게 하면 브라우저가 화면 크기에 따라 적절한 이미지를 자동으로 선택하므로, 모바일에서 데스크톱용 고해상도 이미지를 내려받는 낭비를 막을 수 있습니다. 단, loading="lazy"는 첫 화면 아래에 있는 이미지에만 쓰고, 첫 화면의 LCP 이미지에는 쓰지 마세요.

이미지 검색 노출까지 고려한다면 의미 있는 파일명과 이미지 내용을 설명하는 alt 텍스트를 쓰고, 이미지를 CSS 배경이 아닌 <img> 요소로 넣으세요. 검색엔진은 CSS 배경 이미지를 이미지 콘텐츠로 색인하지 않습니다.

5.16 JavaScript 최적화

JavaScript 최적화의 목표는 첫 화면 표시를 막는 스크립트를 없애고, 메인 스레드를 오래 점유하는 작업을 줄여 LCP와 INP를 함께 개선하는 것입니다. JavaScript는 다운로드·파싱·실행 모두 메인 스레드를 쓰므로, 필요한 코드만 필요한 시점에 불러오는 것이 원칙입니다.

렌더링 차단 JS 제거

<!-- 나쁜 예시: <head>에 blocking JS -->
<script src="heavy-script.js"></script>

<!-- 좋은 예시: defer로 HTML 파싱 후 실행 -->
<script src="script.js" defer></script>

<!-- async: 다운로드 즉시 실행 (순서 무관한 독립 스크립트) -->
<script src="analytics.js" async></script>

코드 스플리팅(Code Splitting)

React, Next.js, Vite 같은 모던 프레임워크에서는 코드 스플리팅으로 해당 화면에 필요한 코드만 불러오세요. 단, 검색엔진이 읽어야 할 본문까지 클라이언트에서 늦게 불러오지 않도록 주의합니다.

// Next.js 동적 임포트 예시
import dynamic from 'next/dynamic';

const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <p>로딩 중...</p>,
});

불필요한 서드파티 스크립트 정리

태그 관리자, 채팅 위젯, A/B 테스트 도구, 광고·분석 스크립트 같은 서드파티 스크립트는 성능, 특히 INP에 큰 영향을 줍니다. 분기마다 목록을 점검해 사용하지 않는 스크립트는 제거하고, 필요한 것은 async나 defer로 불러오거나 사용자가 해당 기능을 쓸 때 불러오도록 바꾸세요.

5.17 CSS 최적화

CSS 최적화의 핵심은 첫 화면에 필요한 CSS만 먼저 적용하고, 사용하지 않는 규칙을 덜어 내 렌더링 차단 시간을 줄이는 것입니다. 브라우저는 CSS를 모두 받기 전까지 화면을 그리지 않으므로, CSS 크기는 LCP에 직접 영향을 줍니다.

크리티컬 CSS(Critical CSS) 인라인

화면 상단(Above-the-fold) 콘텐츠를 그리는 데 필요한 CSS를 HTML에 인라인으로 넣으면, 외부 CSS 파일을 기다리지 않고 바로 화면을 표시할 수 있습니다.

<head>
  <!-- 크리티컬 CSS 인라인 -->
  <style>
    /* 화면 상단 레이아웃에 필요한 최소 CSS */
    body { margin: 0; font-family: sans-serif; }
    header { background: #333; color: white; padding: 1rem; }
  </style>

  <!-- 나머지 CSS는 비동기 로드 -->
  <link rel="preload" href="main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

미사용 CSS 제거

PurgeCSS 같은 도구나 Tailwind CSS의 빌드 과정을 이용해 실제로 쓰지 않는 CSS 규칙을 제거하면 파일 크기를 크게 줄일 수 있습니다. Bootstrap처럼 큰 CSS 프레임워크를 통째로 불러오는 사이트에서 특히 효과적입니다. Chrome 개발자 도구의 ‘Coverage’ 패널로 사용되지 않는 CSS·JS 비율을 확인할 수 있습니다.

5-D. 백엔드 인프라 튜닝

백엔드 인프라 튜닝은 서버가 HTML을 더 빨리 만들어 보내도록 웹 서버, 애플리케이션 캐시, CDN, 전송 프로토콜을 정비해 TTFB(Time To First Byte)를 줄이는 일입니다. TTFB는 LCP의 출발점이므로, 이미지와 스크립트를 최적화했는데도 LCP가 개선되지 않는다면 가장 먼저 살펴볼 영역입니다. 서버 응답이 느리거나 오류가 잦으면 검색엔진의 크롤링 속도도 함께 떨어집니다.

5.18 Nginx 고성능 설정 가이드

Nginx는 기본 설정만으로도 빠른 웹 서버지만, 압축·연결 재사용·캐시 헤더를 조정하면 전송량과 응답 시간을 더 줄일 수 있습니다. 아래 설정은 운영 환경에 적용하기 전에 스테이징에서 먼저 검증하세요.

Gzip / Brotli 압축

HTML, CSS, JavaScript, JSON, SVG 같은 텍스트 리소스는 전송 전에 압축하면 크기가 크게 줄어듭니다. 이미 압축된 JPEG·PNG·WebP·AVIF 이미지는 다시 압축해도 효과가 거의 없으므로 대상에서 뺍니다.

# /etc/nginx/nginx.conf 또는 해당 server 블록

# Gzip 설정
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_proxied expired no-cache no-store private auth;
gzip_types
    text/plain
    text/css
    text/xml
    text/javascript
    application/javascript
    application/x-javascript
    application/xml
    application/json
    image/svg+xml;
gzip_comp_level 6;

# Brotli 설정 (ngx_brotli 모듈 설치 필요)
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

Brotli는 일반적으로 Gzip보다 압축률이 높지만 Nginx 기본 빌드에는 포함되어 있지 않아 ngx_brotli 모듈이 필요합니다. 브라우저가 Accept-Encoding 헤더로 지원하는 방식을 알리면 서버는 그에 맞춰 응답하며, Cloudflare 같은 CDN을 쓰면 CDN 구간에서 압축을 처리하기도 합니다.

Keep-Alive 설정

TCP 연결을 재사용해 리소스마다 새 연결을 맺는 비용을 줄입니다.

keepalive_timeout 65;
keepalive_requests 1000;   # 최근 버전의 기본값. 이보다 낮추지 않습니다

정적 파일 캐싱

# 정적 리소스 캐시 헤더 설정
location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|woff|woff2|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# HTML 파일은 짧은 캐시 (콘텐츠 변경 반영)
location ~* \.html$ {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

expires 1y와 immutable은 app.3f9a2c.css처럼 파일명에 버전 해시가 들어간 정적 파일에만 쓰세요. 파일명이 그대로인 채 내용만 바뀌면 재방문자는 최대 1년 동안 예전 파일을 보게 됩니다.

Worker 프로세스 최적화

# CPU 코어 수에 맞게 설정
worker_processes auto;

# 각 worker당 처리할 수 있는 최대 연결 수
events {
    worker_connections 1024;
    multi_accept on;
    use epoll;  # Linux 최적화
}

5.19 PHP OPcache 설정 및 최적화

OPcache는 PHP 스크립트를 컴파일한 바이트코드를 메모리에 저장해, 요청마다 파싱과 컴파일을 반복하지 않게 하는 PHP 내장 캐시입니다. Laravel, WordPress 같은 PHP 사이트라면 TTFB를 줄이기 위해 가장 먼저 확인해야 할 설정입니다.

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256       ; MB 단위, 사이트 규모에 따라 조정
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000  ; 프로젝트의 PHP 파일 수보다 크게
opcache.validate_timestamps=0        ; 운영 환경: 파일 변경 감지 끔 (배포 시 초기화 필수)
opcache.save_comments=1              ; 어노테이션·속성을 읽는 프레임워크에 필요
opcache.jit=tracing                  ; PHP 8.0+ JIT
opcache.jit_buffer_size=64M

JIT는 계산이 많은 작업에서 효과가 크고, 데이터베이스와 네트워크를 기다리는 시간이 대부분인 일반 웹 요청에서는 체감 효과가 작을 수 있습니다. 적용 전후의 응답 시간을 직접 비교해 보고 결정하세요.

# 배포 후 PHP-FPM 캐시 초기화 (서비스 이름은 설치된 PHP 버전에 맞게)
sudo systemctl reload php8.3-fpm

# Laravel: 설정·라우트·뷰 캐시 생성
php artisan optimize

5.20 Redis / Memcached 캐싱 전략

Redis와 Memcached는 데이터베이스 쿼리 결과, 세션, 계산 비용이 큰 데이터를 메모리에 저장해 같은 요청을 반복 처리하지 않게 하는 인메모리 캐시입니다. 로그인하지 않은 방문자에게 같은 HTML을 보여 주는 페이지라면, 여기에 더해 페이지 전체를 캐시하는 풀 페이지 캐시(Nginx FastCGI 캐시, CDN 캐시 등)가 TTFB를 줄이는 데 특히 효과적입니다.

Laravel에서 Redis 활용

// 데이터베이스 쿼리 결과 캐싱
$posts = Cache::remember('popular_posts', 3600, function () {
    return Post::orderBy('views', 'desc')->take(10)->get();
});

// 세션을 Redis로 처리 (config/session.php)
// 'driver' => 'redis'

// 큐 작업도 Redis로 처리 (config/queue.php)
// 'default' => 'redis'

WordPress + Redis Object Cache

WordPress는 한 페이지를 만들 때 많은 데이터베이스 쿼리를 실행하므로, Redis Object Cache 같은 플러그인으로 영구 객체 캐시를 붙이면 반복 쿼리를 크게 줄일 수 있습니다.

// Redis Object Cache 플러그인 연결 설정
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_DATABASE', 0);

캐시를 도입한 뒤에는 상품 가격, 재고, 게시글 수정처럼 바로 반영돼야 하는 데이터의 캐시 무효화 규칙을 반드시 정해 두세요. 오래된 정보가 검색엔진과 AI 크롤러에 수집되면 잘못된 가격이나 정보가 그대로 인용될 수 있습니다.

5.21 Cloudflare 성능 최적화

Cloudflare는 CDN, DNS, 보안, 성능 최적화를 한 곳에서 제공하는 서비스로, 무료 요금제로도 정적 파일 캐시, HTTPS, 기본 DDoS 방어를 적용할 수 있습니다. 다만 AI 크롤러 설정은 검색 노출에 직접 영향을 주므로 5.9의 점검 순서를 먼저 확인하세요.

기본 설정 체크리스트

SSL/TLS 설정:

• SSL/TLS 암호화 모드: Full (strict). ‘Flexible’은 Cloudflare와 오리진 서버 사이가 암호화되지 않고 리다이렉트 루프를 일으키기 쉬우므로 피합니다.
• Always Use HTTPS 활성화
• HSTS는 모든 하위 도메인에서 HTTPS가 정상 작동하는지 확인한 뒤 활성화
• Minimum TLS Version: TLS 1.2 이상

캐싱 설정:

• Caching Level: Standard
• Browser Cache TTL: 오리진 서버의 캐시 헤더를 따르도록(Respect Existing Headers) 두고, 캐시 기간은 서버에서 파일 유형별로 정합니다.
• Tiered Cache(계층형 캐시)를 켜면 오리진 서버로 가는 요청을 줄일 수 있습니다.

성능 설정:

• HTTP/3 (with QUIC) 활성화
• Rocket Loader는 JavaScript 실행 순서를 바꾸므로 사이트별로 테스트한 뒤에만 켭니다.
• HTML·CSS·JS 압축(minify)은 CDN보다 빌드 단계에서 처리하는 것이 예측 가능하고 안전합니다.

Cache Rules로 경로별 캐시 정책 지정

특정 URL 패턴에 세밀한 캐시 정책을 적용할 때는 Cache Rules를 사용합니다.

# API 경로: 캐시 우회
URI 경로가 /api/ 로 시작    → Bypass cache

# 관리자 페이지: 캐시 우회
URI 경로가 /admin/ 로 시작  → Bypass cache

# 버전 해시가 붙은 정적 리소스: 1년 캐시
URI 경로가 /static/ 로 시작 → Eligible for cache, Edge TTL 1 year

Workers를 활용한 SEO 설정

Cloudflare Workers는 엣지 서버에서 실행되는 서버리스 함수로, 오리진 서버를 고치지 않고 응답 헤더를 바꿀 수 있습니다. 예를 들어 스테이징 도메인이 검색에 색인되는 사고를 막으려면 X-Robots-Tag: noindex를 붙입니다.

export default {
  async fetch(request) {
    const response = await fetch(request);
    const { hostname } = new URL(request.url);

    // 스테이징 호스트는 검색 색인에서 제외
    if (hostname.startsWith('staging.')) {
      const res = new Response(response.body, response);
      res.headers.set('X-Robots-Tag', 'noindex');
      return res;
    }
    return response;
  },
};

예전에는 Googlebot에게만 미리 렌더링한 HTML을 보내는 ‘동적 렌더링’을 Workers로 구현하는 방법이 자주 소개됐지만, 구글은 동적 렌더링을 장기 해결책이 아닌 임시방편으로 규정하고 서버 사이드 렌더링, 정적 렌더링 등을 권장합니다.

5.22 TTFB(Time To First Byte) 단축 전략

TTFB는 브라우저가 요청을 보낸 뒤 서버 응답의 첫 바이트를 받기까지 걸리는 시간으로, DNS 조회·연결·서버 처리 시간을 모두 포함합니다. TTFB 자체는 Core Web Vitals 지표가 아니지만 LCP 시간에 그대로 더해지므로, TTFB가 길면 다른 최적화를 해도 LCP를 ‘좋음’ 기준 안에 넣기 어렵습니다.

TTFB가 긴 주요 원인과 해결책

# 서버의 TTFB를 명령줄에서 간단히 측정 (단위: 초)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://example.com/

5.23 HTTP/2, HTTP/3(QUIC) 적용

HTTP/2와 HTTP/3는 하나의 연결로 여러 리소스를 동시에 주고받게 해 리소스가 많은 페이지의 로딩을 빠르게 하는 전송 프로토콜입니다. 두 프로토콜 모두 브라우저에서는 HTTPS가 전제이므로 SSL 설정과 함께 적용합니다.

HTTP/2의 장점

• 멀티플렉싱: 하나의 TCP 연결로 여러 리소스를 동시에 전송합니다.
• 헤더 압축: HPACK 알고리즘으로 반복되는 헤더를 압축합니다.
• 서버 푸시는 쓰지 않기: Chrome은 HTTP/2 서버 푸시 지원을 중단했습니다. 중요한 리소스는 <link rel="preload">나 103 Early Hints로 미리 알립니다.

# Nginx 1.25.1 이상: http2 지시어 사용
listen 443 ssl;
http2 on;

# 이전 버전에서는 다음 형식을 사용했습니다
# listen 443 ssl http2;

HTTP/3 (QUIC) 적용

HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용해, 패킷 손실이 잦은 모바일 네트워크에서 특히 유리합니다. 서버 방화벽에서 UDP 443 포트를 열어야 합니다.

# Nginx 1.25.0 이상, HTTP/3 모듈을 포함해 빌드한 경우
listen 443 quic reuseport;
listen 443 ssl;
http2 on;
http3 on;
ssl_protocols TLSv1.2 TLSv1.3;   # QUIC은 TLS 1.3을 사용

add_header Alt-Svc 'h3=":443"; ma=86400' always;

Cloudflare를 사용한다면 대시보드에서 HTTP/3를 활성화하는 것만으로 방문자와 Cloudflare 사이 구간에 적용됩니다.

5.24 서버 사이드 렌더링(SSR) vs 정적 사이트(SSG) SEO 비교

검색과 AI 노출이 중요한 페이지는 첫 HTML 응답에 본문이 들어 있는 SSR(서버 사이드 렌더링)이나 SSG(정적 사이트 생성)로 만드는 것이 가장 안전합니다. React, Vue, Angular로 만든 클라이언트 렌더링(CSR) SPA는 구글이 JavaScript를 렌더링하는 단계까지 기다려야 내용이 보이고, AI 크롤러의 JavaScript 처리 방식은 대부분 공개되어 있지 않습니다.

Next.js, Nuxt, SvelteKit 같은 프레임워크는 페이지별로 SSR과 SSG를 섞어 쓸 수 있어 SEO와 성능을 함께 챙기기 좋습니다. 이미 CSR로 만든 서비스라면 검색 유입이 필요한 페이지(랜딩, 상품, 블로그)부터 SSR·SSG로 옮기는 것이 현실적입니다.

5-E. 보안 인프라 구축

보안 인프라는 HTTPS 암호화, 보안 헤더, 웹 방화벽으로 사이트와 방문자를 보호하는 기반이며, 구글은 HTTPS를 검색 순위에 가벼운 신호로 반영합니다. 순위 신호보다 더 큰 이유는 신뢰입니다. 브라우저는 HTTP 페이지에 ‘안전하지 않음’ 경고를 표시하고, 해킹으로 스팸 페이지가 주입된 사이트는 검색 결과에서 경고가 붙거나 순위를 잃을 수 있습니다.

5.25 SSL/TLS 최상위 등급 획득 전략

SSL/TLS 설정의 목표는 오래된 프로토콜과 약한 암호화를 끄고, 인증서가 끊김 없이 자동 갱신되게 만드는 것입니다. SSL Labs 등급 자체는 검색 순위 요소가 아니지만, A 이상의 등급은 설정에 빠진 곳이 없는지 확인하는 좋은 기준이 됩니다.

Nginx SSL 권장 설정

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

    # 최신 TLS 버전만 허용
    ssl_protocols TLSv1.2 TLSv1.3;

    # 강력한 암호화 스위트 (Mozilla SSL Configuration Generator의 Intermediate 설정 참고)
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS (1년). 모든 하위 도메인이 HTTPS일 때만 includeSubDomains 사용
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # SSL 세션 캐시
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
}

HSTS의 preload 옵션은 브라우저에 ‘이 도메인은 항상 HTTPS’라고 미리 등록하는 기능이라 되돌리기가 어렵습니다. 모든 하위 도메인이 HTTPS로 안정적으로 운영되는지 확인한 뒤에만 추가하세요.

Let's Encrypt 인증서 자동 갱신

# Certbot으로 인증서 발급 (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# 자동 갱신 테스트 (패키지로 설치하면 보통 갱신 타이머가 함께 등록됨)
sudo certbot renew --dry-run

# 타이머가 없다면 크론으로 등록 (갱신에 성공했을 때만 Nginx 설정 다시 읽기)
0 0,12 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

5.26 HTTPS 마이그레이션 체크리스트

HTTP에서 HTTPS로 옮길 때 검색 트래픽을 지키는 핵심은 모든 URL을 1:1로 301 리다이렉트하고, 사이트 안의 모든 참조를 HTTPS 주소로 바꾸는 것입니다.

• SSL 인증서 발급 및 설치
• HTTP → HTTPS 301 리다이렉트를 페이지 단위(1:1)로 설정
• 내부 링크, 이미지, CSS, JS URL을 HTTPS로 업데이트
• canonical, hreflang, 구조화 데이터 속 URL을 HTTPS로 업데이트
• robots.txt, sitemap.xml의 URL을 HTTPS로 업데이트
• Google Search Console은 도메인 속성으로 등록해 http·https·www 변형을 한 번에 확인(URL 접두어 속성을 쓴다면 HTTPS 속성을 새로 추가)
• Bing Webmaster Tools와 네이버 서치어드바이저에도 HTTPS 주소가 등록되어 있는지 확인
• GA4 데이터 스트림의 웹사이트 URL을 HTTPS로 확인
• 혼합 콘텐츠(Mixed Content) 오류 해결
• 외부 백링크 중 중요한 것은 HTTPS URL로 수정 요청
• 이전 후 몇 주 동안 ‘페이지 색인 생성’ 보고서와 검색 트래픽을 모니터링

5.27 보안 헤더 설정

보안 헤더는 브라우저에 콘텐츠 해석, 프레임 삽입, 외부 리소스 로드에 관한 보안 정책을 따르도록 지시하는 HTTP 응답 헤더입니다. securityheaders.com에서 현재 설정을 확인할 수 있습니다.

# MIME 타입 스니핑 방지
add_header X-Content-Type-Options "nosniff" always;

# 클릭재킹 방지 (CSP의 frame-ancestors와 함께 사용)
add_header X-Frame-Options "SAMEORIGIN" always;

# 참조자 정책
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# 권한 정책 (불필요한 기능 비활성화)
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

# Content Security Policy (사이트에 맞게 조정. 먼저 Content-Security-Policy-Report-Only로 시험)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:; frame-ancestors 'self'" always;

• X-XSS-Protection은 넣지 않습니다: 예전 가이드에 흔한 이 헤더는 최신 브라우저에서 지원이 중단되었고 오히려 부작용을 낳을 수 있어, 설정하지 않거나 0으로 두는 것이 권장됩니다. XSS 방어는 CSP로 합니다.
• 인라인 스크립트: 태그 관리자 설치 코드처럼 인라인 스크립트가 필요하면 'unsafe-inline' 대신 nonce나 hash로 허용합니다.
• Nginx 상속 주의: location 블록 안에 add_header가 하나라도 있으면 상위 블록의 헤더가 상속되지 않습니다. 공통 헤더 파일을 각 블록에서 include하세요.

5.28 Cloudflare WAF와 봇 관리

WAF(Web Application Firewall)는 SQL 인젝션, XSS 같은 웹 공격 요청을 서버에 닿기 전에 걸러 내는 방화벽입니다. 다만 방화벽과 봇 차단 규칙이 너무 공격적이면 검색엔진과 AI 검색 크롤러까지 막을 수 있으므로, 적용 후 크롤링 상태를 반드시 확인해야 합니다.

기본 WAF 설정

• 보안 설정의 WAF 관리형 규칙(Managed Rules)을 활성화합니다. 요금제에 따라 제공되는 규칙 세트(Cloudflare Managed Ruleset, OWASP Core Ruleset 등)가 다릅니다.
• 관리자 로그인 경로에는 국가·IP 제한이나 추가 인증 규칙을 둡니다.

봇 관리

악성 봇은 서버 자원을 소모해 응답을 느리게 만들고, 그만큼 검색엔진 크롤링에도 악영향을 줍니다.

• Bot Fight Mode 등 봇 방어 기능과, 의심스러운 트래픽에 대한 Rate Limiting 규칙을 설정합니다.
• Cloudflare가 확인된 봇(Verified Bots)으로 분류한 Googlebot, bingbot, Yeti 등이 사용자 정의 규칙에 막히지 않는지 보안 이벤트 로그에서 확인합니다.
• AI 크롤러별 허용·차단 정책은 5.9의 설정과 robots.txt를 기준으로 일관되게 관리합니다.

5-F. 모바일 우선 전략

모바일 우선 색인(Mobile-first indexing)은 구글이 페이지의 모바일 버전을 기준으로 크롤링·색인·평가하는 방식이며, 구글은 이 전환을 마치고 대부분의 사이트를 스마트폰용 Googlebot으로 크롤링합니다. 데스크톱에서 완벽해 보여도 모바일 버전에 콘텐츠가 빠져 있으면 그 콘텐츠는 검색에서 없는 것으로 취급될 수 있습니다.

5.29 모바일 우선 색인 대응

모바일 우선 색인에 대응하는 핵심은 모바일 버전이 데스크톱 버전과 같은 콘텐츠, 같은 메타데이터, 같은 구조화 데이터를 갖게 하는 것입니다.

• 모바일에서도 데스크톱과 같은 본문, 제목, 이미지, 동영상이 표시되는지 확인
• 탭·아코디언 속 콘텐츠도 HTML에 들어 있으면 색인된다는 점을 활용하되, 클릭해야 서버에서 불러오는 방식은 피하기
• title, meta description, robots 메타 태그, 구조화 데이터가 모바일과 데스크톱에서 같은지 확인
• 이미지 지연 로딩이 스크롤이나 클릭 같은 사용자 동작을 요구하지 않는지 확인(브라우저 기본 loading="lazy" 사용 권장)
• 모바일 페이지의 Core Web Vitals(LCP, INP, CLS)가 기준을 충족하는지 확인
• 별도 모바일 URL(m. 도메인)을 운영한다면 데스크톱과 모바일 페이지 사이의 canonical·alternate 연결이 정확한지 확인하고, 가능하면 반응형으로 통합

5.30 반응형 디자인 SEO 체크리스트

반응형 디자인은 하나의 URL과 HTML로 모든 기기에 대응하는 방식으로, 구글이 권장하는 모바일 구성 방식입니다. URL이 하나라서 링크 신호가 나뉘지 않고, 크롤러가 같은 페이지를 두 번 수집할 필요도 없습니다.

<!-- 반응형 디자인 필수 메타 태그 -->
<meta name="viewport" content="width=device-width, initial-scale=1">

모바일 사용성 체크포인트:

• 글자 크기: 확대하지 않고도 읽을 수 있는 본문 크기(일반적으로 16px 안팎)
• 터치 영역: 버튼과 링크는 손가락으로 누르기 쉬운 크기와 간격을 확보합니다. 웹 접근성 기준 WCAG 2.2는 최소 24×24 CSS 픽셀(AA), 강화 기준으로 44×44 CSS 픽셀(AAA)을 제시합니다.
• 가로 스크롤 없음: 표와 코드 블록처럼 넓은 요소는 해당 요소 안에서만 스크롤되게 합니다.
• 전면 팝업 자제: 페이지에 들어오자마자 콘텐츠를 가리는 전면 팝업(intrusive interstitial)은 사용자 경험을 해치며, 구글도 피하라고 안내합니다.
• 점검 도구: 구글의 모바일 친화성 테스트 도구는 종료되었으므로 Lighthouse와 Chrome 개발자 도구의 기기 모드, 실제 스마트폰으로 확인합니다.

5.31 AMP — 현재 유효성 재검토

AMP(Accelerated Mobile Pages)는 모바일 페이지를 빠르게 표시하기 위한 프레임워크이며, 2026년 현재 AMP 자체는 검색 순위에 이점을 주지 않습니다. 2021년 페이지 경험 업데이트 이후 구글 검색의 ‘주요 뉴스(Top Stories)’ 노출에도 AMP가 더 이상 필수가 아니게 되면서, AMP를 새로 도입할 이유는 크게 줄었습니다.

• Core Web Vitals를 충족하면 AMP 없이도 같은 목표(빠른 모바일 경험)를 달성할 수 있습니다.
• 기존 AMP 페이지는 유지해도 되지만, 두 버전을 함께 관리하는 비용을 따져 보세요.
• AMP를 제거할 때는 AMP URL을 원래(정규) 페이지로 리다이렉트해 링크와 색인 신호를 넘깁니다.
• 신규 프로젝트에는 AMP보다 Core Web Vitals 최적화에 자원을 쓰는 것이 효율적입니다.

PART 5 요약 및 독자별 체크리스트

PART 5의 핵심은 크롤러가 접근할 수 있고, AI 크롤러 정책이 의도대로 설정되어 있으며, 페이지가 빠르고 안정적이고, 서버가 안전하게 응답하는 사이트를 만드는 것입니다. 아래 요약과 역할별 체크리스트로 현재 상태를 점검해 보세요.

이 파트의 항목을 바탕으로 사이트 전체를 점검하는 기술 SEO 진단이 필요하다면 SEO AEO의 SEO 서비스를 참고하세요. 신규 사이트 런칭이나 사이트 이전 때 쓸 수 있는 전체 점검표는 PART 11. SEO 실무 워크플로우와 체크리스트에 정리되어 있습니다.