Multi Site Directory Network on Headless WordPress

Challenge

Location directories carry requirements that pull against each other. Administrators want a familiar content management interface. Visitors want pages that load immediately across thousands of listings. The listing data itself has to come from somewhere, be kept current, and stay consistent across every site.

Traditional WordPress answers the first well and struggles with the rest. Dynamic page generation slows as listing counts grow, and a directory with thousands of entries cannot be populated by hand.

Solving that once is a project. Solving it so the same platform can launch the second directory, and the sixth, is a different problem.

Solution

84EM built a headless system where WordPress handles content management and the public-facing directories are pre-built as static pages. There is no database query when a visitor loads a page.

Listing data is imported from the the Google Places API. Where a listing arrives without a description, one is generated with AI rather than left blank. Listing images are handled by Cloudflare Images, so they are never processed or stored in WordPress, thus reducing the server resources needed.

Administrators manage all content. Visitors can submit a listing through a public suggestion form. Suggestions are one input into an editorial workflow.

The architecture is multi-tenant by design. One shared theme and one shared WordPress backend serve every directory in the network, with per-site configuration and content supplying the brand, the taxonomy and the copy. Each site builds independently from the same codebase, so a fix or a feature written once reaches all of them.

Key Capabilities

  • Sourced listing data. Listings are imported from the Google Places API rather than entered by hand, which is what makes a directory of this size practical to launch and maintain.
  • AI-filled gaps. Listings that arrive without a description get one generated, so no entry publishes empty.
  • Offloaded images. Cloudflare Images handles storage and delivery, keeping image weight and processing entirely out of WordPress.
  • Static delivery. Every page is pre-built and served as a static file, so traffic volume has no bearing on response time and spikes need no additional infrastructure.
  • Public suggestions, editorial control. Anyone can suggest a listing without creating an account, and administrators approve, edit, or reject before anything appears.
  • Scheduled publishing. Sites rebuild on a daily schedule. Each build is verified before it goes live, swapped in atomically, health-checked, and rolled back automatically if the new version fails its checks.
  • Location-based organization. Dedicated pages for states, cities, and individual listings support both browsing and full-text search.
  • One platform, many directories. Shared theme and backend with per-site overrides, so launching another directory is a configuration exercise rather than a rebuild.

Results

The platform currently runs six live directories, covering vintage stores, coffee shops, vegan spots, dog parks, splash pads, and food pantries.

Each site delivers fast page loads regardless of traffic volume. Traffic spikes don’t require additional infrastructure and don’t cause degradation.

Publishing is deliberately scheduled rather than immediate. Directory content does not change minute to minute, so a daily rebuild trades instant updates for a publishing path that verifies its own output and can roll itself back. Administrators can also trigger a rebuild on demand when something needs to go out sooner.

The architecture has held up as the network grew from one directory to six, which is the part worth noting. The delivery model and the data pipeline were designed for a single site and did not need rethinking to serve several.

Have a similar challenge?

Describe what you're dealing with. If it looks anything like this, you'll get a straight answer on what it would take.

Folks we've helped.