디렉토리 웹사이트 구축: CMS 도구가 10,000개 목록에서 실패하는 이유
디렉토리 웹사이트: CMS 도구가 10,000개 목록에서 망가지는 이유
이런 상황을 최소 12번은 봤습니다. 누군가 Webflow나 WordPress에서 디렉토리를 만들고, 500개 목록에서는 정말 멋지게 작동하고, 2,000개에서도 여전히 괜찮다가, 8,000~10,000개 항목 근처에서 갑자기 시스템이 숨을 헐떡이기 시작합니다. 검색이 느려지고, 필터가 타임아웃되고, 빌드 시간이 몇 분으로 늘어납니다. 1개월 차에는 완벽했던 CMS가 8개월 차에는 반드시 탈출해야 할 병목이 됩니다.
근본적인 문제는 무엇일까요? CMS 도구는 콘텐츠를 위해 설계되었습니다 — 블로그 게시물, 랜딩 페이지, 기껏해야 수백 개의 SKU가 있는 제품 카탈로그. 디렉토리 웹사이트는 완전히 다른 종류의 문제입니다. 복잡한 필터링, 패싯 검색, 지리위치 쿼리, 사용자 생성 콘텐츠, 페이지뷰당 데이터베이스 조회 수를 몇 배로 늘리는 페이지네이션 패턴이 필요합니다. 디렉토리를 더 많은 게시물이 있는 블로그처럼 취급하는 것은 생각보다 훨씬 빨리 따라잡히는 아키텍처 실수입니다.
이것이 정확히 왜 일어나는지, 2025년의 실제 기술적 한계가 무엇인지, 그리고 10,000개 이상의 목록으로 확장하려고 진지하게 생각한다면 대신 무엇을 구축해야 하는지 설명하겠습니다.
목차
- 디렉토리는 블로그가 아닙니다
- 주요 CMS 플랫폼이 벽에 부딪히는 곳
- 기술적 현실: 10K가 분기점인 이유
- 실제로 작동하는 방식: 확장을 위한 아키텍처
- 디렉토리 웹사이트를 위한 헤드리스 접근법
- 비용 비교: CMS vs. 헤드리스 vs. 커스텀
- 실제 마이그레이션 경로
- FAQ
디렉토리는 블로그가 아닙니다
당연해 보이지만 프로젝트가 계획 단계에서 잘못되는 곳입니다. 블로그 게시물은 단일 문서입니다. slug로 가져오고 렌더링하고 끝입니다. 디렉토리 목록 페이지는 완전히 다른 작업을 수행합니다. 잠재적으로 수천 개의 레코드를 쿼리하고, 여러 필터를 동시에 적용하고(카테고리, 위치, 가격 범위, 평가, 가용성), 결과를 정렬하고, 페이지를 매기고, 페이지를 렌더링합니다 — 종종 지도 마커, 거리 계산, 각 필터 옵션의 집계 수를 포함합니다.
페이지뷰당 데이터베이스 작업의 빠른 비교입니다:
| 작업 | 블로그 게시물 페이지 | 디렉토리 목록 페이지 |
|---|---|---|
| 주 쿼리 | 1 (slug로 가져오기) | 1 (필터됨, 정렬됨, 페이지네이션됨) |
| 관련 쿼리 | 2-3 (작성자, 카테고리, 관련 게시물) | 5-15 (필터 수, 지리 계산, 리뷰, 가용성) |
| 인덱스 조회 | 1-2 | 10-50+ (필터 패싯당) |
| 스캔된 행 | 1-5 | 100-10,000+ |
| 일반적인 응답 시간 | 5-50ms | 200-2,000ms (최적화되지 않음) |
| 캐시 무효화 복잡성 | 낮음 (단일 문서) | 높음 (모든 목록 변경이 여러 페이지에 영향) |
전통적인 CMS를 사용할 때, 이러한 모든 작업은 동일한 데이터베이스, 동일한 쿼리 엔진, 홈페이지, 소개 페이지, 관리 패널도 제공하는 동일한 서버를 통해 진행됩니다. 500개 목록에서는 상관없습니다. 10,000개에서는 매우 큰 문제입니다.
주요 CMS 플랫폼이 벽에 부딪히는 곳
무엇이 망가지고 어디서 망가지는지 구체적으로 살펴봅시다.
Webflow
Webflow는 Business 플랜에서 컬렉션당 10,000개의 CMS 항목에 대한 하드 캡을 적용합니다. 이것은 소프트 지침이 아닙니다 — 벽입니다. 이것을 건드리면 문자 그대로 다른 목록을 추가할 수 없습니다. Webflow 팀은 커뮤니티 포럼에서 이 한계가 "성능 이유로" 존재하며 사라지지 않을 것이라고 확인했습니다.
하지만 대부분의 사람들이 놓치는 것이 있습니다: 10K에 도달하기 훨씬 전에 성능이 저하됩니다. 복잡한 컬렉션 목록과 필터가 있는 5,000~6,000개 항목을 지나면, 빌드 시간이 10분을 넘어가고 페이지 로드가 느려지는 것을 알 수 있습니다. Webflow의 CMS는 패싯 검색을 위해 만들어지지 않았습니다. "5마일 이내의 모든 레스토랑을 보여줘. 지금 열어있고 채식 옵션이 있는" 쿼리를 기본 지원하는 방법이 없습니다.
2026년 3월 기준, Webflow의 Business 플랜은 $39/월입니다(연간 청구). 추가 기능으로 20,000개 항목으로 늘리고 싶습니까? $124/월이 들 것입니다 — 기본 가격의 3배 이상으로 항목 수는 두 배입니다. 100K 이상 항목에 대한 엔터프라이즈 가격은 연간 $15,000-$50,000부터 시작합니다.
WordPress
WordPress는 하드 항목 캡이 없지만 더 나쁜 것이 있습니다: 예측 불가능한 성능 저하입니다. Directorist나 Business Directory Plugin 같은 디렉토리 플러그인이 있는 표준 WordPress 설치는 일반적인 공유 또는 VPS 호스팅에서 약 10,000개 목록 근처에서 어려움을 겪기 시작합니다. 원인은 MySQL 쿼리 성능입니다.
WordPress는 모든 것을 저장합니다 — 게시물, 커스텀 필드, 분류법, 메타데이터 — 한 줌의 데이터베이스 테이블에. 20개의 커스텀 필드가 있는 디렉토리 목록은 목록당 wp_postmeta에서 20개 행을 의미합니다. 10,000개 목록에서, 그것은 wp_postmeta만 200,000행이고, WordPress는 이 테이블들 간에 JOIN 쿼리를 하는 것을 좋아합니다. WooCommerce 또는 wp_postmeta에도 데이터를 집어넣는 다른 플러그인을 추가하면 실제 문제가 됩니다.
10K 목록에서 정상적으로 작동하는 WordPress 디렉토리 사이트를 봤습니다 — 하지만 중요한 최적화 이후에만: Redis 객체 캐싱, Elasticsearch 검색, 전용 데이터베이스 서버, 신중한 쿼리 최적화. 그 시점에서, 당신은 월 $200-500을 호스팅 인프라에 쓰고 있으며 기본적으로 플랫폼과 함께 일하기보다는 싸우고 있습니다.
Airtable / Notion / Google Sheets를 "백엔드"로 사용하기
저는 인디 해커 커뮤니티에서 이 패턴을 끊임없이 봅니다. Airtable을 데이터베이스로 사용하고, 정적 사이트 생성기나 Webflow를 통해 파이프하면, 당신은 디렉토리를 얻습니다. 작동합니다! 어느 시점까지는요.
Airtable의 API는 요청당 최대 100개의 레코드를 반환합니다. 그들의 무료 플랜은 베이스당 1,200개의 레코드로 제한됩니다. Business 플랜($20/사용자/월)도 베이스당 초당 5개 요청의 속도 제한에 걸립니다. 10,000개 목록이 있는 디렉토리 페이지를 렌더링하려고 시도하면, 단일 페이지가 로드되기 전에 100개의 순차적 API 호출을 하고 있습니다. 그것은 디렉토리가 아닙니다 — 로딩 스피너입니다.
기술적 현실: 10K가 분기점인 이유
10,000개 목록 임계값은 자의적이지 않습니다. 이것은 일반적인 CMS 구성 하에서 데이터베이스가 어떻게 행동하는지의 상 전환을 나타냅니다.
쿼리 복잡성이 폭발합니다
10K 목록에서, 일반적인 필터된 디렉토리 쿼리는 다음을 수행해야 합니다:
- 필터를 적용하기 위해 테이블(또는 인덱스)의 잠재적으로 큰 부분을 스캔합니다
- 남은 필터 옵션에 대한 집계 수를 계산합니다 ("호텔 (247), 레스토랑 (1,832)")
- 관련성, 거리 또는 평가로 결과를 정렬합니다
- 페이지네이션하고 부분 집합을 반환합니다
- 관련 데이터를 조인합니다 (이미지, 리뷰, 카테고리)
적절하게 인덱싱된 PostgreSQL 데이터베이스와 적절한 스키마 설계에서, 이것은 10-50ms를 소요합니다. WordPress의 wp_posts + wp_postmeta 스키마와 EAV 패턴 쿼리에서? 쉽게 500-2,000ms. 콘텐츠 페이지를 위해 설계된 Webflow의 내부 데이터 계층에서? 그것이 그들이 캡을 적용하는 이유입니다.
빌드 시간이 개발자 경험을 죽입니다
정적 사이트 생성기 — Webflow와 많은 헤드리스 설정 모두 사용 — 모든 목록, 모든 카테고리 페이지, 모든 필터된 조합에 대한 페이지를 빌드해야 합니다. 10,000개 목록에 50개의 카테고리 페이지가 있으면, 최소 10,050개 이상의 정적 페이지를 생성하고 있습니다. Webflow로, 빌드는 20분을 초과할 수 있습니다. Next.js와 getStaticPaths를 사용하면, ISR(Incremental Static Regeneration)을 사용하지 않는 한 전체 리빌드에 15-30분을 기다려야 합니다.
// 순진한 접근: 빌드 시 모든 10K 페이지를 빌드합니다
export async function getStaticPaths() {
const listings = await fetchAllListings(); // 10,000 항목
return {
paths: listings.map(l => ({ params: { slug: l.slug } })),
fallback: false // 모든 페이지를 미리 빌드합니다
};
}
// 스마트한 접근: 필요할 때 빌드합니다
export async function getStaticPaths() {
// 가장 조회수가 많은 상위 100개 목록만 미리 빌드합니다
const topListings = await fetchTopListings(100);
return {
paths: topListings.map(l => ({ params: { slug: l.slug } })),
fallback: 'blocking' // 다른 페이지를 첫 요청에서 빌드한 후 캐시합니다
};
}
검색이 실제 문제가 됩니다
10,000개 이상의 목록에서 여러 필드(이름, 설명, 태그, 위치, 카테고리)에 대한 전문 검색은 대부분의 CMS 도구가 완전히 무너지는 곳입니다. WordPress의 기본 검색은 LIKE %term% 쿼리입니다 — 문자 그대로 모든 행을 스캔합니다. Webflow의 기본 필터링은 전문 검색을 지원하지 않습니다.
실제 디렉토리 검색은 다음이 필요합니다:
- 유사성 매칭 ("piza"를 입력할 때 "pizza" 찾기)
- 가중 관련성 (제목 일치는 설명 일치보다 높게 순위)
- 패싯 수 (카테고리/필터당 결과 수)
- 지리 거리 정렬
- 200ms 미만의 응답 시간
이를 위해서는 검색 엔진이 필요합니다. Elasticsearch, Meilisearch, Typesense, 또는 Algolia. 이들 중 어느 것도 전통적인 CMS에 내장되어 있지 않습니다.
실제로 작동하는 방식: 확장을 위한 아키텍처
10,000개 이상의 목록을 처리해야 하는 디렉토리를 구축하는 경우, 처음부터 관심을 분리해야 합니다.
올바른 데이터 계층
당신의 목록은 특정 쿼리 패턴을 위해 설계된 스키마가 있는 적절한 데이터베이스에 있어야 합니다. CMS 콘텐츠 모델에 있지 않고, 스프레드시트에 있지 않고, 메타데이터가 달린 일반 posts 테이블에 있지 않습니다.
-- 목적에 맞는 목록 테이블
CREATE TABLE listings (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT NOT NULL,
slug TEXT UNIQUE NOT NULL,
description TEXT,
category_id UUID REFERENCES categories(id),
location GEOGRAPHY(POINT, 4326), -- 지리 쿼리를 위한 PostGIS
price_range INT CHECK (price_range BETWEEN 1 AND 4),
rating DECIMAL(3,2),
is_verified BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT NOW(),
updated_at TIMESTAMPTZ DEFAULT NOW()
);
-- 디렉토리 쿼리 패턴을 위한 적절한 인덱스
CREATE INDEX idx_listings_category ON listings(category_id);
CREATE INDEX idx_listings_location ON listings USING GIST(location);
CREATE INDEX idx_listings_rating ON listings(rating DESC);
CREATE INDEX idx_listings_search ON listings USING GIN(
to_tsvector('english', name || ' ' || COALESCE(description, ''))
);
PostGIS가 있는 PostgreSQL은 100,000개 이상의 목록을 문제없이 처리합니다. Supabase는 이것을 기본으로 제공하며 관대한 무료 티어와 수백만 행으로 확장합니다. 이것이 우리가 우리의 헤드리스 CMS 개발 프로젝트에서 구현하는 종류의 데이터 아키텍처입니다 — CMS는 편집 콘텐츠를 처리하는 동안 데이터베이스는 대규모 구조화된 데이터를 처리합니다.
스토리지에서 검색 분리하기
주 데이터베이스가 검색을 처리하도록 하지 마세요. 당신의 목록을 전용 검색 서비스와 동기화하세요:
| 검색 서비스 | 무료 티어 | 10K+ 레코드에서의 가격 | 지연시간 | 최적 용도 |
|---|---|---|---|---|
| Algolia | 10K 검색/월 | $1/1K 요청 + $0.40/1K 레코드 | <50ms | 최대 속도, 패싯 |
| Typesense | 자체 호스팅 (무료) | 클라우드: $29.50/월 (최대 500K 레코드) | <50ms | 예산 친화적, 오픈 소스 |
| Meilisearch | 자체 호스팅 (무료) | 클라우드: $30/월 (1M 문서) | <50ms | 간단한 설정, 좋은 기본값 |
| Elasticsearch | 자체 호스팅 (무료) | Elastic Cloud: ~$95/월 | <100ms | 복잡한 쿼리, 성숙한 생태계 |
Typesense와 Meilisearch는 2025년을 통해 모두 크게 성숙했습니다. 100K 미만의 목록이 있는 대부분의 디렉토리 프로젝트의 경우, $29.50/월의 Typesense Cloud는 즉시 검색, 패싯, 지리 검색, 오타 허용을 제공합니다. 그것은 황당하게 빠릅니다.
디렉토리 웹사이트를 위한 헤드리스 접근법
10,000개를 초과하는 목록이 되기를 예상하는 모든 디렉토리에 권장하는 아키텍처는 다음과 같습니다:
- 프론트엔드: 공개 웹사이트를 위한 Next.js 또는 Astro
- CMS: 편집 콘텐츠를 위한 Sanity, Contentful, 또는 Payload (홈페이지, 소개, 블로그, 도움말 문서)
- 데이터베이스: 목록 데이터를 위한 PostgreSQL (Supabase 또는 Neon을 통해)
- 검색: 검색 및 필터링을 위한 Typesense 또는 Meilisearch
- 관리 인터페이스: 목록 관리를 위한 커스텀 대시보드 또는 Retool
이것은 우리가 클라이언트를 위해 정기적으로 구축하는 종류의 스택입니다. 프론트엔드 프레임워크는 렌더링과 라우팅을 처리합니다. CMS는 편집자가 관리해야 하는 콘텐츠를 처리합니다. 데이터베이스는 구조화된 대용량 목록 데이터를 처리합니다. 검색 엔진은 디렉토리가 요구하는 쿼리 패턴을 처리합니다.
Next.js를 사용하면, 목록 세부 정보 페이지에 대해 ISR을 얻습니다 (필요할 때 페이지 빌드, 가장자리에서 캐시, 변경 시 재검증) 및 검색/필터 페이지에 대해 서버 측 렌더링 (항상 최신 결과, 빠른 응답). Astro를 사용하면, 자주 변경되지 않는 목록을 위한 더 빠른 정적 페이지를 얻고, 검색 및 필터링을 위한 상호 작용의 섬을 얻습니다.
// Next.js App Router: 목록 페이지에 대한 ISR
export async function generateStaticParams() {
// 순간 로드를 위해 상위 목록만 미리 빌드합니다
const topListings = await db
.select({ slug: listings.slug })
.from(listings)
.orderBy(desc(listings.pageviews))
.limit(500);
return topListings.map(l => ({ slug: l.slug }));
}
export const revalidate = 3600; // 매시간 재검증
export default async function ListingPage({ params }) {
const listing = await db
.select()
.from(listings)
.where(eq(listings.slug, params.slug))
.limit(1);
if (!listing[0]) notFound();
return <ListingDetail listing={listing[0]} />;
}
CMS로 모든 것을 하면 안 되는 이유가 뭔가요?
CMS 플랫폼은 편집 워크플로, 데이터 작업에 최적화되어 있지 않기 때문입니다. CMS는 리치 텍스트 편집, 초안/발행 워크플로, 콘텐츠 스케줄링, 지역화, 역할 기반 권한을 제공합니다. 이들은 블로그 게시물과 마케팅 페이지에 필수적입니다.
디렉토리 목록은 이것 중 어느 것도 필요하지 않습니다. 대량 가져오기/내보내기, 구조화된 검증 (이것이 유효한 전화번호인가?), 중복 제거, 자동 보강 (Google Places 데이터 끌어오기), 그리고 데이터 소스를 스크래핑할 때 500개의 동시 쓰기를 처리할 수 있는 능력이 필요합니다. 이들은 데이터베이스 작업입니다. 콘텐츠 작업이 아닙니다.
실수는 콘텐츠 관리와 데이터 관리를 혼동하는 것입니다. 그들은 다른 문제이며 다른 솔루션이 필요합니다.
비용 비교: CMS vs. 헤드리스 vs. 커스텀
25,000개 목록이 있는 디렉토리를 운영하는 것의 실제 월별 비용을 살펴봅시다:
| 비용 범주 | Webflow (엔터프라이즈) | WordPress (최적화) | 헤드리스 (Next.js + Supabase) | 완전 커스텀 |
|---|---|---|---|---|
| 호스팅/플랫폼 | $1,250-$4,166/월 | $100-300/월 (관리형 WP) | $20/월 (Vercel Pro) | $200-500/월 (클라우드 인프라) |
| 데이터베이스 | 포함 (제한됨) | 포함 (MySQL) | $25/월 (Supabase Pro) | $50-200/월 (관리형 PG) |
| 검색 | 기본적으로 사용할 수 없음 | $0-95/월 (Elasticsearch) | $29.50/월 (Typesense Cloud) | $95-300/월 (Elasticsearch) |
| CMS | 포함 | 무료 (WP 코어) | $0-99/월 (Sanity/Payload) | 해당 없음 |
| CDN/Edge | 포함 | $0-20/월 | 포함 (Vercel) | $20-50/월 |
| 총 월별 | $1,250-$4,166 | $100-415 | $75-175 | $365-1,050 |
| 빌드 비용 | $5K-15K | $3K-10K | $15K-40K | $50K-150K+ |
헤드리스 접근법은 WordPress 플러그인을 함께 집어넣는 것보다 더 높은 초기 빌드 비용이 있습니다. 의심의 여지가 없습니다. 하지만 진행 중인 비용은 Webflow 엔터프라이즈보다 훨씬 낮으며, 아키텍처는 실제로 성장을 지원합니다. 25K에서 100K 목록으로 이동할 때, Supabase 플랜과 검색 티어를 범프합니다. 그것뿐입니다. 재아키텍처 없음, 마이그레이션 패닉 없음.
이 특정 프로젝트의 비용이 어떻게 될지 평가하고 있다면, 우리의 가격 페이지는 우리의 참여 모델을 분석하거나, 당신의 디렉토리의 요구사항에 대해 논의하기 위해 직접 문의할 수 있습니다.
실제 마이그레이션 경로
이미 CMS 천장에 갇혀 있다면, 다음은 실용적인 마이그레이션 순서입니다:
단계 1: 데이터 추출 (주 1-2)
CMS에서 모든 것을 내보냅니다. Webflow의 API와 CSV 내보내기가 작동합니다. WordPress는 wp-cli export가 있습니다. 당신의 목록을 깨끗한 CSV 또는 JSON 형식으로 가져옵니다.
단계 2: 새 데이터 계층 설정 (주 2-3) PostgreSQL으로 가져오기는 적절한 스키마 설계를 합니다. Typesense를 설정하고 당신의 데이터와 동기화합니다. 검색 품질과 쿼리 성능을 확인합니다.
단계 3: 새 프론트엔드 구축 (주 3-8) 새 백엔드에 대해 검색, 필터링, 목록 세부 정보 페이지, 카테고리 페이지를 다시 구축합니다. 이것은 Next.js 또는 Astro가 빛나는 곳입니다 — 데이터 아키텍처를 완전히 바꾸면서 기존 설계를 복제할 수 있습니다.
단계 4: 편집 콘텐츠를 위해 CMS를 유지합니다 (지속적) CMS를 홈페이지 콘텐츠, 블로그 게시물, 도움말 문서, 편집 콘텐츠에 사용합니다. 데이터베이스가 목록을 처리하도록 하세요. 그들은 평화롭게 공존합니다.
단계 5: 리다이렉트 및 시작 (주 8-10) 구 URL에서 새로운 URL로 301 리다이렉트를 설정하고, Google Search Console에서 검증하고, 모니터링합니다. URL 구조가 동일하게 유지되면 (그렇게 해야 함), SEO 자산을 유지합니다.
FAQ
Webflow가 정말 큰 디렉토리 웹사이트를 처리할 수 있습니까?
Webflow는 5,000개 미만의 목록이 있는 디렉토리에 잘 작동합니다. 5K와 10K 사이에서, 빌드 시간과 페이지 로드에 대한 성능 드래그를 느낄 것입니다. 10,000에서 당신은 하드 캡을 타격합니다. 당신의 디렉토리가 작게 유지되고 Webflow의 시각적 설계 도구를 원한다면, 괜찮습니다. 성장을 예상한다면, 다른 아키텍처로 시작하세요.
10,000개 이상의 목록이 있는 디렉토리를 구축하는 가장 저렴한 방법은 무엇입니까?
WordPress with Directorist는 품질의 관리형 호스팅 (Cloudways 또는 SpinupWP 같은)에서 월 $30-50을 실행하며 적절한 캐싱 및 최적화로 10K-50K 목록을 처리할 수 있습니다. 가장 저렴한 경로입니다. 트레이드오프는 진행 중인 유지보수 두통, 플러그인 충돌, 그리고 단순히 괜찮은 것보다 좋은 검색 경험입니다.
Supabase가 디렉토리 데이터베이스에 충분히 좋습니까?
절대적으로. Supabase는 PostGIS 지원, 행 수준 보안, 실시간 구독과 함께 PostgreSQL을 실행합니다. 그들의 Pro 플랜은 $25/월이며 수백만 행을 문제없이 처리합니다. 500K 미만 목록의 대부분 디렉토리 프로젝트의 경우, 그것은 당신의 돈의 최고 가치입니다. 당신은 합리적인 관리 UI와 내장된 API 계층이 있는 적절한 관계형 데이터베이스를 얻습니다.
큰 디렉토리의 검색과 필터링을 처리하려면 어떻게 합니까?
검색을 위해 주 데이터베이스를 사용하지 마세요. 당신의 목록을 Typesense, Meilisearch, 또는 Algolia와 동기화하세요. 이 서비스들은 즉시, 패싯, 오타 허용 검색을 위해 목적으로 만들어졌습니다. Typesense Cloud는 $29.50/월에서 시작하며 최대 500K 레코드를 처리합니다. 검색 경험은 CMS가 기본적으로 제공하는 어떤 것보다 훨씬 더 좋을 것입니다.
디렉토리를 위해 정적 사이트 생성기 또는 서버 측 렌더링을 사용해야 합니까?
목록 세부 정보 페이지의 경우, ISR (Incremental Static Regeneration)로 정적 생성을 사용하세요 — 페이지는 첫 방문에서 빌드하고 가장자리에서 캐시합니다. 검색 및 필터 페이지의 경우, 서버 측 렌더링을 사용하면 결과가 항상 최신이고 응답이 빠릅니다. Next.js App Router는 동일한 프로젝트에서 두 패턴을 모두 지원합니다. Astro with server islands는 당신의 디렉토리가 더 읽기 위주인 경우 또 다른 강력한 옵션입니다.
10,000개 이상의 목록을 디렉토리로 가져오려면 어떻게 합니까?
수동 프로세스가 아닌 가져오기 파이프라인을 구축합니다. CSV/JSON 소스를 읽고, 각 레코드를 검증하고, 기존 항목과 중복을 제거하고, 데이터베이스에 일괄 삽입하는 스크립트를 작성합니다. PostgreSQL의 COPY 명령 또는 Supabase의 일괄 삽입 API는 10K 레코드를 몇 초 안에 처리할 수 있습니다. 그런 다음 검색 인덱스에 대한 동기화를 트리거합니다. 저는 CMS 관리 UI를 통해 이것을 하려고 시도하는 사람들을 봤습니다 — 하지 마세요. 영원히 걸리고 아마도 타임아웃될 것입니다.
디렉토리 웹사이트의 수천 개 페이지에 대한 SEO는 어떻게 합니까?
디렉토리 SEO는 적절한 XML 사이트맵 (사이트맵 파일당 최대 50K URL로 분할), 각 목록당 고유한 메타 설명, 구조화된 데이터 (LocalBusiness 또는 Product 스키마), 그리고 카테고리와 목록 사이의 내부 링크가 필요합니다. 헤드리스 접근법은 실제로 여기를 돕습니다. 당신은 모든 메타 태그와 스키마 마크업의 모든 것을 완전히 제어할 수 있기 때문입니다. CMS는 종종 규모에서 페이지당 무엇을 커스터마이즈할 수 있는지 제한합니다.
완전 커스텀 대신 헤드리스로 가는 것이 언제 합리적입니까?
완전 커스텀 (CMS/관리 계층을 포함한 모든 것을 처음부터 구축)는 100K 이상의 목록을 지나갈 때 합리적입니다, 복잡한 매칭 알고리즘이 필요할 때 (양측 마켓플레이스처럼), 실시간 데이터 피드가 필요할 때, 또는 기존 도구가 처리하지 않는 고유한 비즈니스 논리가 있을 때. 그 아래 임계값에서, 헤드리스 아키텍처는 당신에게 90%의 이점을 비용의 20%로 제공합니다. 우리가 보는 대부분의 디렉토리 프로젝트는 완전 커스텀이 필요하지 않습니다 — 그들은 잘 아키텍처된 헤드리스 빌드가 필요합니다.