How We Built a Programmatic SEO Engine Serving 80K+ Pages on WordPress (Without Using wp_posts)

Context

WordPress의 기본 wp_posts 테이블에 80,000개 이상의 포스트를 저장할 경우 쿼리 성능이 5ms에서 500ms로 저하되고, wp_postmeta 조인으로 인해 800,000개 이상의 행이 발생하며, 관리자 패널의 "모든 포스트" 화면 로딩이 불가능해진다. XML 사이트맵 플러그인은 타임아웃되거나 메모리를 소비하고, 리비전 히스토리가 실제 콘텐츠의 3~4배에 달한다.

Technical Solution

• 커스텀 데이터베이스 테이블 설계: wp_posts 대신 sc_cities, sc_businesses, sc_calculations_cache 테이블을 생성해 적절한 데이터 타입, 인덱싱(idx_country, idx_slug, idx_category), 정규화를 적용
• 가상 URL 라우팅 구현: WordPress 리라이트 API를 활용해 ^start-a-([^/]+)-in-([^/]+)/?$ 패턴을 등록하고 query_vars 필터로 sc_business, sc_city 변수를 인식
• 템플릿 인터셉트: template_redirect 훅에서 플러그인이 요청을 가로채 wp_posts 접근 없이 페이지를 렌더링
• 계산 결과 캐싱: 도시와 사업 유형의 인기 조합에 대해 total_cost와 breakdown JSON을 sc_calculations_cache에 사전 계산해 저장
• 청크 기반 사이트맵 생성: 전체 80,000개 페이지를 단일 XML 대신 여러 사이트맵 파일로 분할해 생성하고 주간 cron으로 재생성
• 내부 링크 전략: 각 도시 페이지에서 해당 도시의 모든 사업 유형으로, 각 사업 유형 페이지에서 상위 도시로, 비용 프로필이 유사한 페이지로 링크해 검색 엔진의 발견과 이해를 지원

Impact

아티클에서 구체적인 성능 수치가 명시되지 않았으므로 이 섹션을 생략합니다.

Key Takeaway

WordPress의 기본 데이터 모델을 따르지 않고도 커스텀 테이블, 가상 라우팅, 프로그래매틱 렌더링으로 대규모 정적 콘텐츠를 서빙할 수 있다. 데이터베이스 스키마 설계가 쿼리 성능의 근본 요인이므로 렌더링 로직 작성 전에 투자해야 한다.