기술적 SEO (Technical SEO)

기술적 SEO는 "콘텐츠가 아무리 좋아도 구글이 제대로 읽지 못하면 의미가 없다"는 전제에서 시작합니다. 크롤링, 인덱싱, 사이트 속도, 보안, 서버 설정 — 이 모든 요소가 검색 순위에 직접적인 영향을 미칩니다. 특히 개발자라면 이 파트에서 가장 많은 실전 액션 아이템을 찾을 수 있을 것입니다.

5-A. 크롤링 & 인덱싱

5.1 robots.txt 작성 가이드

robots.txt는 웹사이트 루트 디렉토리에 위치하는 텍스트 파일로, 검색엔진 크롤러에게 어떤 페이지를 크롤링해도 되고 하면 안 되는지를 알려줍니다.

기본 문법

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

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

자주 차단해야 하는 경로

User-agent: *
Disallow: /admin/
Disallow: /wp-admin/         # WordPress 관리자
Disallow: /cart/             # 장바구니
Disallow: /checkout/         # 결제
Disallow: /my-account/       # 회원 마이페이지
Disallow: /search/           # 내부 검색 결과
Disallow: /tag/              # 태그 아카이브 (내용이 빈약한 경우)
Disallow: /?s=               # WordPress 검색 파라미터
Allow: /

robots.txt의 치명적인 실수

가장 흔하고 치명적인 실수는 중요한 페이지를 실수로 차단하는 것입니다. 스테이징 서버의 robots.txt가 프로덕션 서버에 그대로 배포되면, 사이트 전체가 구글에서 사라질 수 있습니다.

배포 전에 반드시 Disallow: / 같은 전체 차단 설정이 없는지 확인하세요.

AI 크롤러 관리

GEO 시대에는 AI 크롤러 설정도 중요합니다.

# AI 크롤러 허용 (GEO를 원한다면)
User-agent: GPTBot        # OpenAI ChatGPT
Allow: /

User-agent: PerplexityBot # Perplexity AI
Allow: /

User-agent: anthropic-ai  # Claude
Allow: /

User-agent: Google-Extended # Google AI 학습 데이터
Allow: /                    # AI Overview에 등장하려면 허용 권장

AI 학습 데이터 제공을 원하지 않지만 AI Overview 인용은 원한다면, Google-Extended는 차단하되 Googlebot은 허용하는 설정이 가능합니다.

5.2 XML Sitemap 생성 및 제출

XML Sitemap은 사이트의 모든 중요 페이지 목록을 구글에게 알려주는 파일입니다. 사이트가 클수록, 내부 링크가 부족할수록 사이트맵의 중요성이 커집니다.

기본 사이트맵 구조

<?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-03-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

사이트맵 유형

• sitemap_index.xml: 여러 개의 사이트맵을 묶는 인덱스 파일. 페이지가 50,000개 이상이거나 사이트맵을 여러 종류로 나눌 때 사용합니다.
• Post Sitemap: 블로그 포스트 전용
• Page Sitemap: 일반 페이지 전용
• Image Sitemap: 이미지 URL 포함 (이미지 검색 최적화)
• Video Sitemap: 동영상 콘텐츠 포함
• News Sitemap: 뉴스 사이트 전용 (최근 48시간 이내 콘텐츠)

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

사이트맵에는 인덱싱을 원하는 URL만 포함해야 합니다.

• noindex가 설정된 페이지
• 리다이렉트(301/302)되는 URL
• 404 오류 페이지
• 중복 콘텐츠 페이지
• 로그인이 필요한 페이지

GSC에 사이트맵 제출

Google Search Console → Sitemaps → 사이트맵 URL 입력 → 제출

제출 후 상태가 "성공"으로 표시되는지 확인하고, 정기적으로 오류가 발생하지 않는지 모니터링하세요.

5.3 크롤 버짓(Crawl Budget) 관리

크롤 버짓은 구글봇이 특정 기간 동안 사이트에 할당하는 크롤링 횟수입니다. 사이트 규모가 크거나 서버 응답이 느리면 크롤 버짓 문제가 발생할 수 있습니다.

크롤 버짓이 낭비되는 원인

• 파라미터 URL 과다: 필터, 정렬, 추적 파라미터로 수천 개의 중복 URL이 생성
• 무한 페이지네이션: 끝없이 이어지는 페이지 목록
• 세션 ID URL: ?sessionid=abc123 형태의 URL
• 저품질 페이지 과다: 얇은 콘텐츠 페이지, 빈 카테고리 페이지
• 느린 서버 응답: 응답이 느리면 구글봇이 크롤링 빈도를 낮춤

크롤 버짓 최적화 방법

• 파라미터 URL에 noindex 또는 canonical 적용
• robots.txt로 불필요한 경로 차단
• 저품질 페이지를 noindex 처리 또는 삭제
• 서버 응답 속도 개선 (TTFB 감소)
• 내부 링크를 정리해 크롤링 경로 단순화

5.4 404 & 301 리다이렉트 전략

404 오류 관리

404 오류(페이지 없음)가 많으면 크롤 버짓이 낭비되고, 해당 페이지로 연결된 백링크의 권위도 손실됩니다.

GSC에서 404 오류 확인: Google Search Console → Coverage → Excluded → "Not found (404)" 탭

404 처리 방법:

1. 콘텐츠가 이동되었다면 → 새 URL로 301 리다이렉트
2. 유사한 콘텐츠가 있다면 → 가장 관련성 높은 페이지로 301 리다이렉트
3. 콘텐츠가 완전히 사라졌다면 → 홈페이지 또는 관련 카테고리로 301 리다이렉트

301 vs 302 리다이렉트

• 301 (영구 이동): 링크 권위가 완전히 전달됩니다. URL을 영구적으로 변경할 때 사용하세요.
• 302 (임시 이동): 링크 권위가 완전히 전달되지 않습니다. A/B 테스트, 임시 유지보수 페이지 등 일시적인 상황에서만 사용하세요.

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

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

# 디렉토리 전체 리다이렉트
location /old-category/ {
    return 301 https://example.com/new-category/;
}

# www → non-www 리다이렉트
server {
    listen 80;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

5.5 Pagination & Infinite Scroll 처리

콘텐츠가 많은 사이트에서 페이지네이션은 올바르게 처리하지 않으면 크롤링과 인덱싱에 문제를 일으킵니다.

페이지네이션 처리 방법

• 각 페이지를 독립적으로 인덱싱: /category/page/2/, /category/page/3/를 각각 인덱싱 허용. 단, 1페이지 내용만 가치 있는 경우 2페이지 이후에 noindex 적용.
• View All 페이지: 모든 항목을 한 페이지에 보여주는 "View All" 페이지를 만들고 canonical을 설정하는 방법도 있으나, 페이지 속도 저하에 주의하세요.

Infinite Scroll 처리

Infinite Scroll은 구글봇이 JavaScript를 완전히 실행하지 못하면 첫 화면만 크롤링될 수 있습니다.

• 각 항목에 고유 URL이 있다면 sitemap에 모두 포함하세요.
• HTML fallback으로 페이지네이션 링크를 함께 제공하는 것이 안전합니다.

5-B. 사이트 속도 최적화 (Core Web Vitals)

5.6 Core Web Vitals 완전 이해 — LCP, INP, CLS

Core Web Vitals는 구글이 공식 랭킹 신호로 사용하는 사용자 경험 지표입니다. 2024년에 FID(First Input Delay)가 INP(Interaction to Next Paint)로 교체되어 현재 세 가지 지표로 구성됩니다.

LCP (Largest Contentful Paint) — 로딩 성능

화면에서 가장 큰 콘텐츠 요소(이미지, 텍스트 블록 등)가 렌더링되는 시간입니다.

LCP 개선 방법:

• 히어로 이미지를 WebP로 변환하고 fetchpriority="high" 속성 추가
• <link rel="preload">로 LCP 리소스를 미리 로드
• TTFB (Time To First Byte) 단축
• 서버 사이드 렌더링 또는 정적 생성 활용

INP (Interaction to Next Paint) — 반응성

사용자가 페이지와 상호작용(클릭, 키보드 입력 등)했을 때 다음 화면이 업데이트되는 시간입니다.

INP 개선 방법:

• 무거운 JavaScript 실행 최소화
• Long Task(50ms 이상 메인 스레드를 차지하는 작업) 분리
• React 등 프레임워크에서 불필요한 재렌더링 최소화
• Web Worker를 활용한 백그라운드 처리

CLS (Cumulative Layout Shift) — 시각적 안정성

페이지 로딩 중 레이아웃이 얼마나 이동하는지를 측정합니다. 읽고 있는 내용이 갑자기 이동하는 경험을 수치화한 것입니다.

CLS 개선 방법:

• 모든 이미지와 비디오에 width와 height 속성 명시
• 광고, 임베드 콘텐츠의 공간을 미리 예약
• 웹폰트 로딩 중 텍스트 이동 방지 (font-display: optional 또는 swap)
• 동적으로 삽입되는 콘텐츠를 페이지 하단에 배치

5.7 PageSpeed Insights & GTmetrix 활용법

Google PageSpeed Insights (PSI)

pagespeed.web.dev에서 URL을 입력하면 Lab 데이터와 Field 데이터 두 가지를 제공합니다.

• Field Data (실제 사용자 데이터): CrUX(Chrome User Experience Report) 기반의 실제 사용자 경험 데이터입니다. 이것이 구글 순위에 실제 영향을 미치는 데이터입니다.
• Lab Data (시뮬레이션 데이터): Lighthouse를 사용한 시뮬레이션 결과입니다. 개선 방향 파악에 유용하지만, 실제 사용자 경험과 다를 수 있습니다.

Field Data가 없거나 "Poor" 등급이라면 이것이 최우선 개선 대상입니다.

GTmetrix

gtmetrix.com은 Lighthouse와 Web Vitals를 함께 제공하며, 국가별 테스트, 워터폴 차트, 히스토리 추적 기능이 강점입니다.

워터폴 차트 활용법:

• 가장 긴 막대를 가진 리소스 확인 → 해당 리소스가 병목 지점
• TTFB가 길면 서버 설정 문제
• CSS/JS 파일이 렌더링을 차단하고 있는지 확인

5.8 WebPageTest & Lighthouse 심층 분석

WebPageTest

webpagetest.org는 가장 심층적인 성능 분석을 제공하는 무료 툴입니다. 특히 다음 기능이 강력합니다.

• Filmstrip View: 페이지가 로딩되는 과정을 0.5초 단위로 스크린샷으로 보여줍니다. 어느 시점에 콘텐츠가 나타나는지 직관적으로 확인할 수 있습니다.
• Connection View: 각 리소스의 DNS, TCP, SSL, 응답 시간을 상세히 표시합니다.
• Repeat View: 재방문 시 캐시가 올바르게 작동하는지 확인합니다.

Chrome DevTools Lighthouse

브라우저 개발자 도구(F12)에서 Lighthouse 탭으로 직접 분석이 가능합니다. 로컬 개발 환경에서 빠른 성능 측정이 필요할 때 유용합니다.

# CLI로 Lighthouse 실행
npx lighthouse https://example.com --output html --output-path ./report.html

5.9 이미지 최적화 — CDN, 포맷, 압축

이미지는 대부분의 웹페이지에서 전체 용량의 50~70%를 차지합니다. 이미지 최적화는 Core Web Vitals 개선에서 가장 효과적인 단일 작업입니다.

이미지 압축 파이프라인

빌드 타임 압축 (권장):

# Node.js 환경
npm install sharp

# sharp를 이용한 WebP 변환 예시
const sharp = require('sharp');
sharp('input.jpg')
  .webp({ quality: 80 })
  .toFile('output.webp');

서버 사이드 실시간 변환:

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"
/>

이렇게 하면 브라우저가 화면 크기에 따라 적절한 이미지를 자동으로 선택합니다. 모바일에서 데스크탑용 고해상도 이미지를 다운로드하는 낭비를 막을 수 있습니다.

5.10 JavaScript 최적화

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>,
});

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

Google Tag Manager, 채팅 위젯, A/B 테스트 툴 등 서드파티 스크립트는 성능에 큰 영향을 미칩니다. 사용하지 않는 스크립트는 즉시 제거하고, 필요한 것은 async 또는 defer로 로드하세요.

5.11 CSS 최적화

Critical CSS (인라인 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 같은 툴을 사용해 실제로 사용되지 않는 CSS 규칙을 제거하면 파일 크기를 크게 줄일 수 있습니다. 특히 Bootstrap, Tailwind 같은 대형 CSS 프레임워크를 사용할 때 효과적입니다.

5-C. 서버 & 인프라 최적화

5.12 Nginx 설정 최적화

Nginx는 가장 널리 사용되는 웹 서버 소프트웨어입니다. 올바른 Nginx 설정만으로도 사이트 속도를 획기적으로 개선할 수 있습니다.

Gzip / Brotli 압축

텍스트 기반 리소스(HTML, CSS, JS)를 전송 전에 압축하면 전송 크기가 70~80% 감소합니다.

# /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보다 압축률이 20~30% 높지만, 모든 서버에 기본 탑재되어 있지는 않습니다. 브라우저는 Accept-Encoding 헤더로 지원 여부를 알려주며, Nginx는 자동으로 적합한 압축 방식을 선택합니다.

Keep-Alive 설정

TCP 연결을 재사용해 각 리소스마다 새로운 연결을 맺는 오버헤드를 줄입니다.

keepalive_timeout 65;
keepalive_requests 100;

정적 파일 캐싱

# 정적 리소스 캐시 헤더 설정
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";
}

Worker 프로세스 최적화

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

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

5.13 PHP OPcache 설정 및 최적화

PHP로 운영되는 사이트(Laravel, WordPress 등)에서 OPcache는 TTFB를 획기적으로 줄여줍니다. OPcache는 PHP 스크립트를 컴파일된 바이트코드로 캐싱해, 매 요청마다 스크립트를 파싱하고 컴파일하는 과정을 건너뜁니다.

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256       ; MB 단위, 사이트 규모에 따라 조정
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=0            ; 프로덕션에서는 0 (재검증 비활성화)
opcache.validate_timestamps=0        ; 프로덕션에서는 0 (파일 변경 감지 비활성화)
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=100M         ; PHP 8.0+ JIT 컴파일러
opcache.jit=tracing                  ; PHP 8.0+ JIT 모드

# OPcache 리셋 (배포 스크립트에 포함)
php -r "opcache_reset();"
# 또는
php artisan opcache:clear  # Laravel

5.14 Redis / Memcached 캐싱 전략

데이터베이스 쿼리 결과, 세션, 계산이 복잡한 데이터를 메모리에 캐싱하면 응답 속도가 크게 향상됩니다.

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 플러그인을 사용하면 데이터베이스 쿼리 횟수를 90% 이상 줄일 수 있습니다.

define('WP_CACHE', true);
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);

5.15 Cloudflare CDN 설정 완전 가이드

Cloudflare는 단순한 CDN을 넘어 DNS, DDoS 방어, WAF, 성능 최적화를 통합 제공하는 플랫폼입니다. 무료 플랜만으로도 상당한 성능 개선이 가능합니다.

기본 설정 체크리스트

SSL/TLS 설정:

• SSL/TLS 탭 → Encryption mode: Full (strict) 선택
• Always Use HTTPS 활성화
• HSTS 활성화 (max-age 최소 6개월 이상)
• Minimum TLS Version: TLS 1.2 이상

캐싱 설정:

• Caching → Configuration → Caching Level: Standard
• Browser Cache TTL: 1년 (정적 리소스)
• Tiered Cache 활성화 (Pro 플랜 이상): 오리진 서버 부하 90%까지 감소

성능 설정:

• Speed → Optimization
  • Auto Minify: HTML, CSS, JS 모두 활성화
  • Brotli: 활성화
  • Rocket Loader: 사이트별로 테스트 후 활성화 (JS 사이트에 따라 오히려 문제 발생 가능)
  • HTTP/2: 자동 활성화
  • HTTP/3 (QUIC): 활성화

Cloudflare Page Rules / Cache Rules

특정 URL 패턴에 대해 세밀한 캐싱 정책을 적용할 수 있습니다.

# API 경로 캐싱 비활성화
/api/* → Cache Level: Bypass

# 관리자 페이지 캐싱 비활성화
/admin/* → Cache Level: Bypass

# 정적 리소스 1년 캐시
/static/* → Cache Level: Cache Everything, Edge Cache TTL: 1 year

Workers를 활용한 고급 설정

Cloudflare Workers는 엣지 서버에서 실행되는 서버리스 함수입니다. SEO 관련 활용 예시:

// 특정 User-Agent를 특정 페이지로 리다이렉트
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const userAgent = request.headers.get('User-Agent') || ''

  // 봇 트래픽에 사전 렌더링된 HTML 제공 (SSR 미사용 SPA의 경우)
  if (userAgent.includes('Googlebot')) {
    const prerenderedUrl = `https://prerender.io/https://${new URL(request.url).host}${new URL(request.url).pathname}`
    return fetch(prerenderedUrl)
  }

  return fetch(request)
}

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

TTFB는 브라우저가 서버에 요청을 보내고 첫 번째 바이트를 받기까지의 시간입니다. LCP에 직접적인 영향을 미칩니다.

목표 TTFB: 200ms 이하 (Cloudflare 등 CDN 엣지 기준)

TTFB가 긴 주요 원인과 해결책

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

HTTP/2의 장점

• 멀티플렉싱: 하나의 TCP 연결로 여러 리소스를 동시에 전송
• 헤더 압축: HPACK 알고리즘으로 반복 헤더 압축
• 서버 푸시: 클라이언트 요청 전에 서버가 미리 리소스를 전송 (현재는 효과 불확실)

# Nginx HTTP/2 설정 (SSL 필수)
listen 443 ssl http2;

HTTP/3 (QUIC) 적용

HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용합니다. 패킷 손실이 많은 모바일 네트워크에서 특히 효과적입니다.

# Nginx HTTP/3 설정 (nginx 1.25+ 필요)
listen 443 quic reuseport;
listen 443 ssl;
ssl_protocols TLSv1.3;

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

Cloudflare를 사용한다면 설정에서 HTTP/3를 활성화하는 것만으로 자동 적용됩니다.

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

JavaScript 프레임워크(React, Vue, Angular)로 만든 SPA(Single Page Application)는 SEO에 취약할 수 있습니다. 구글봇이 JavaScript를 렌더링하는 데 딜레이가 있기 때문입니다.

Next.js, Nuxt.js, SvelteKit은 SSR과 SSG를 유연하게 결합할 수 있어 SEO와 성능을 동시에 만족시킬 수 있는 현재 가장 권장되는 선택입니다.

5-D. 보안 & 신뢰성

5.19 SSL/TLS 설정 — SSL Labs A+ 등급 달성

SSL Labs(ssllabs.com/ssltest)에서 A+ 등급을 받으면 구글이 신뢰하는 보안 수준임을 확인받는 것입니다. A+ 등급 달성은 기술적 SEO와 보안 두 마리 토끼를 잡는 작업입니다.

Nginx SSL 최적 설정

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

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

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

    # 강력한 암호화 스위트 (Mozilla 권장)
    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년, includeSubDomains, preload)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

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

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
}

Let's Encrypt 인증서 자동 갱신

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

# 자동 갱신 크론 설정
0 0,12 * * * certbot renew --quiet --post-hook "nginx -s reload"

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

HTTP에서 HTTPS로 마이그레이션할 때 SEO 손실을 방지하기 위한 체크리스트입니다.

• SSL 인증서 발급 및 설치
• HTTP → HTTPS 301 리다이렉트 설정
• 내부 링크, 이미지, CSS, JS URL을 HTTPS로 업데이트
• Canonical Tag를 HTTPS URL로 업데이트
• robots.txt, sitemap.xml의 URL을 HTTPS로 업데이트
• GSC에 HTTPS 버전 사이트를 새로 등록 및 기본 속성으로 설정
• Google Analytics에서 기본 URL을 HTTPS로 변경
• 혼합 콘텐츠(Mixed Content) 오류 해결
• 외부 백링크 중 중요한 것은 HTTPS URL로 업데이트 요청

5.21 보안 헤더 설정

보안 헤더는 브라우저에게 특정 보안 정책을 따르도록 지시합니다. securityheaders.com에서 현재 설정을 확인할 수 있습니다.

# XSS 방어 (현대 브라우저에서는 CSP가 대체)
add_header X-XSS-Protection "1; mode=block" always;

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

# Clickjacking 방지
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 (사이트에 맞게 커스터마이즈 필요)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; img-src 'self' data: https:;" always;

5.22 Cloudflare WAF & DDoS 방어

Cloudflare의 WAF(Web Application Firewall)는 SQL Injection, XSS, CSRF 등의 웹 공격을 자동으로 차단합니다.

기본 WAF 설정

• Security → WAF → Managed Rulesets → Cloudflare Managed Ruleset 활성화
• OWASP Core Ruleset 활성화

Bot 관리

악성 봇은 서버 리소스를 낭비하고 크롤 버짓을 침해합니다.

• Security → Bots → Bot Fight Mode 활성화
• 의심스러운 트래픽 패턴에 대한 Rate Limiting 규칙 설정

5-E. 모바일 & 구조

5.23 Mobile-First Indexing 대응

구글은 2021년부터 모든 사이트에 Mobile-First Indexing을 적용합니다. 구글봇이 모바일 버전을 기준으로 페이지를 크롤링하고 평가한다는 의미입니다.

Mobile-First Indexing 대응 체크리스트:

• 모바일에서도 데스크탑과 동일한 콘텐츠가 표시되는지 확인
• 모바일에서 숨겨진 콘텐츠(탭, 아코디언 등)도 인덱싱됨을 인지
• 모바일에서 이미지가 올바르게 표시되는지 확인
• 모바일에서 구조화된 데이터가 올바르게 적용되는지 확인
• 모바일 페이지 속도(LCP, INP, CLS)가 충족되는지 확인
• 모바일 버전에 데스크탑과 다른 canonical이 설정되어 있지 않은지 확인

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

반응형 디자인은 하나의 HTML로 모든 기기에 대응하는 방식으로, 구글이 가장 권장하는 모바일 구성 방식입니다.

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

모바일 SEO 체크포인트:

• 텍스트 크기: 최소 16px 이상
• 탭 타겟(버튼/링크): 최소 44x44px 이상
• 가로 스크롤 없음
• 팝업/인터스티셜: 모바일에서 콘텐츠를 가리는 팝업은 순위 불이익

5.25 AMP — 현재 유효성 재검토

AMP(Accelerated Mobile Pages)는 구글이 모바일 페이지 속도를 높이기 위해 추진했던 프레임워크입니다. 그러나 2021년 이후 구글이 AMP를 순위 보너스의 요건에서 제외하면서, AMP의 SEO 이점은 크게 줄었습니다.

2026년 AMP 현황:

• AMP 자체가 순위에 영향을 미치지 않습니다.
• Core Web Vitals를 달성하면 AMP 없이도 동일한 효과를 얻을 수 있습니다.
• 기존 AMP 페이지를 운영 중이라면 유지해도 무방하지만, 신규 적용은 권장하지 않습니다.
• 리소스를 Core Web Vitals 최적화에 집중하는 것이 더 효율적입니다.

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