A publishing gate for 53,000 server-rendered pages

The problem with static builds

When a site has about 53,000 possible pages and a business profile edit can change any of them, rebuilding a static site is not practical. Each edit would require regenerating a large portion of the site, and the delay between an edit and the updated page would depend on build time.

Server rendering on Workers and D1

The site runs Astro 5 with server rendering on Cloudflare Workers, using a D1 database for storage. Each request reaches a Worker that queries D1 for the current data and renders the HTML. Because rendering happens on demand, an edit to a profile is visible on the next request without a build step.

The pages table as a publishing gate

Not every record in the database is ready to be public. A separate pages table acts as a publishing gate. For a given page identifier, if there is no published row in that table, the Worker renders the page with a noindex meta tag and does not add the page to the sitemap.

This pattern separates content from publication. The content rows can change at any time, and the pages table controls which of the 53,000 possible pages are actually part of the public site. When a business edits its profile, the rendered page updates immediately, but the set of published pages remains stable unless someone changes the pages table. Separating publication state from content avoids coupling content edits to index visibility, so a data change cannot accidentally expose or hide a page without an explicit publication decision. Keeping these concerns separate also reduces the blast radius of a content edit: a routine change to a profile does not require a corresponding change to the publication table, and a publication change does not require rewriting or revalidating the underlying content. The public index becomes deterministic at request time because the decision to serve a page with noindex or to include it in the sitemap is based on a single explicit row rather than on derived state. In systems where content and publication are mixed, every content update must be checked for side effects on visibility; with a gate, that check is centralized.

The impact on the front end

The design system uses plain CSS tokens and primitives without a CSS framework.

On meumat.co.il, each page request is handled by the Worker, which checks the pages table before returning HTML. If the page is not published, the response includes noindex and the page is omitted from the sitemap. This keeps the public index aligned with the publishing decisions, even though the underlying data changes frequently.

A check in code

A simplified view of the gate looks like this:

if (await db.pages.get(pageId)) {
  return renderPublicPage(data);
} else {
  return renderPrivatePage(data, { noindex: true });
}

This is not the actual implementation, but it shows the shape: a single lookup in the pages table decides whether the page is part of the public site.

The pages table is a small abstraction but a useful one when the content and the set of public pages are different concerns.