A multi-site platform should share engineering effort without making every website look, read, or rank the same. The central design challenge is deciding what belongs in code and what belongs in configuration.
Keep behavior in code and identity in data
Reusable behavior belongs in the shared application: routing, article rendering, schema generation, offer tracking, authentication, and deployment logic. A site's identity should be stored separately. That includes its domain, language, logo, colors, metadata templates, enabled features, and editorial settings.
This separation gives each domain a clear identity while allowing fixes and improvements to ship once. A new accessibility improvement, for example, can reach every tenant without copying components between repositories.
Resolve the site before rendering content
Every request needs a deterministic tenant-resolution step. In production, resolve the incoming hostname against the site registry. In local development, an explicit site ID can provide a safe override. The resolved site object should then drive metadata, branding, content queries, navigation, and feature flags.
Avoid silently falling back to an unrelated tenant. A missing domain mapping should produce a controlled error or a platform landing page. Silent fallbacks create duplicate content and can expose the wrong offers under the wrong brand.
Give every domain independent SEO signals
Shared components do not require shared metadata. Each site needs its own:
- canonical origin and URL rules;
- title and description templates;
- organization and website schema;
- sitemap and robots configuration;
- language and hreflang settings;
- internal-link graph;
- Search Console property.
Content should be scoped by site ID at the database layer. This prevents one tenant's article from appearing in another tenant's sitemap or related-content module.
Treat templates as starting points, not finished sites
A useful template demonstrates a complete route structure, responsive styling, metadata, and content components. When a template becomes a real website, clone its configuration record rather than its source files. The new tenant can then evolve independently through database-backed settings.
Deploy independently
Independent Cloudflare Workers allow each site to have its own domain bindings, environment values, rollback history, and release timing. Record every deployment with its commit, status, target worker, and configured domains. This makes a shared codebase operationally safe: a failed tenant deployment does not erase the history of another.
A practical launch checklist
Before activating a new domain, verify the following:
- The hostname resolves to exactly one site record.
- Canonical URLs use the production HTTPS origin.
- The site has unique homepage and article metadata.
- Sitemap output contains only that tenant's URLs.
- Navigation, forms, and offers work on mobile.
- The Worker and custom domain are recorded in deployment history.
- Search Console and analytics use the correct property IDs.
The result is a platform that scales operationally without sacrificing the signals that make each website useful and discoverable.