"WordPress를 정적 HTML로 내보내기"는 쉬운 부분입니다——이미 여러 플러그인이 이를 해줍니다. 이 이전이 성공할지를 진짜로 좌우하는 것은, 순수 콘텐츠 페이지가 아닌 모든 것에 무슨 일이 생기느냐입니다：댓글, 사이트 내 검색, 문의 폼, 그리고（스토어를 운영하고 있다면） WooCommerce의 가격과 장바구니. 대책 없는 정적 내보내기는 이것들을 그대로 전부 망가뜨립니다.

단순한 정적 내보내기가 망가뜨리는 것

  • 댓글——정적 파일 위에서는 PHP가 실행되지 않아 댓글 제출을 받을 수 없습니다.
  • 검색——WordPress의 검색은 데이터베이스 쿼리 한 번입니다；정적 사이트에는 조회할 데이터베이스가 없습니다.
  • 문의 폼——폼 플러그인은 정적 출력물에는 더 이상 존재하지 않는 PHP 처리 엔드포인트로 전송하려 합니다.
  • WooCommerce의 가격, 재고, 장바구니——요청 시점에 최신 상태여야 하는 것은 몇 시간 또는 며칠 전에 생성된 정적 파일에 구워 넣을 수 없습니다.

해결책：포기가 아니라 프록시

실행 가능한 방법은, WordPress 설치를 지금 돌아가는 그대로——같은 호스트, 같은 데이터베이스, 같은 플러그인——계속 운영하면서, 진짜 WordPress에 도달해야 하는 소수의 요청을 제외한 모든 것을 엣지에서 정적으로 제공하는 것입니다. 정적 사이트 앞단의 라우터（Pinery Static은 Cloudflare Worker를 사용）가 들어오는 요청을 검사해, 댓글 제출, 검색 쿼리, 폼 제출, WooCommerce 가격／장바구니 요청을 진짜 WordPress 백엔드로 조용히 전달하고, 일반적인 페이지 로드는 모두 정적 내보내기에서 즉시 제공됩니다.

이전 단계, 대략적인 순서

  1. WordPress 백엔드를 그대로 둔다. 이를 호스팅 이전의 일부로 만들지 마세요——백엔드는 계속 운영되며, 프록시가 실제로 대화하는 대상이 됩니다.
  2. 완전한 정적 내보내기를 실행하고, 공개 전에 출력 결과에 눈에 띄는 문제가 없는지 확인합니다——이는 누락된 페이지나 형식이 잘못된 URL을 조기에 발견하는 시점입니다.
  3. 정적 출력물을 직접 관리하는 Cloudflare Pages 프로젝트로 배포합니다.
  4. 프록시 라우터를 앞단에 배치해 동적 요청이 정적인 404에 부딪히지 않고 WordPress로 전달되게 합니다.
  5. 도메인을 새 배포로 가리킵니다——이상적으로는 다운타임 없는 동일 도메인 이전 경로를 사용합니다.
  6. 이후에는 증분 방식으로 재내보내기합니다. 콘텐츠를 발행하거나 업데이트할 때마다 변경된 페이지만 재내보내면 되고, 사이트 전체를 다시 할 필요가 없습니다.

완료 후 얻게 되는 것

CDN 엣지에서 제공되는 정적 페이지는 WordPress가 직접 제공할 수 있는 어떤 방식보다도 빠릅니다——PHP 실행 없음, 데이터베이스 쿼리 없음, 요청마다 발생하는 플러그인 오버헤드 없음——한편 댓글, 검색, 폼, 스토어 기능은 네이티브가 아니라 프록시를 거칠 뿐 이전과 똑같이 작동합니다. 이것이 제휴 전환율에 왜 중요한지는 성능 가이드를, 정적 내보내기 도구를 전반적으로 비교하고 있다면 Simply Static과 WP2Static과의 비교도 참고하세요.