One codebase, many affiliate sites is the pattern Simplepage uses to run multiple affiliate content sites from a single Umbraco 17 solution - each site with its own domain, theme, affiliate accounts and content, all sharing one engine underneath. The payoff is speed: a new brand goes live in half a day rather than the weeks a from-scratch build takes. The first public site on the engine is Bayr, our Isle of Man tourism guide with 188 places and attractions. This post covers how the engine works, why Umbraco 17 suits the pattern better than v13, and how the theming layer keeps 90% of new sites down to a single CSS file.
Why build one codebase for many affiliate sites?
Affiliate sites are a cheap-and-cheerful category of web project: content sites that monetise through commission links to booking partners, tours, accommodation and tickets. There are dozens of profitable examples. There are also hundreds of dead ones, abandoned because the effort-to-revenue ratio didn't clear.
The pattern we saw, across our own experiments and client conversations, was this: the first affiliate site takes weeks to build, and the fifth one takes weeks too, because every site reinvents the same infrastructure. Different themes, but the same jobs underneath - manage listings, integrate booking APIs, build categories, display a map, embed reviews.
One codebase, many sites fixes that. Build the generic platform once, then spin up a new site as a theme and a set of content nodes, not a new solution.
How does the multi-site engine work?
The engine is a single Umbraco 17 solution serving multiple hostnames, each with its own content root, its own theme, its own affiliate accounts, its own tax and currency rules. A new site is created by:
Cloning a content template under a new root node
Assigning a hostname (or several) to that root
Swapping in a theme (a CSS variables set plus a few optional Razor partial overrides)
Plugging in that site's affiliate credentials
That's it. A new brand, live on the same infrastructure, in half a day.
Underneath, everything interesting is shared:
Content model: one set of document types (Destination, Activity, Accommodation, Food & Drink, Event, News, etc.) with per-site content sitting under per-site root nodes
Affiliate layer: a set of integrations we wrote once (Booking.com, GetYourGuide, Skyscanner, Amazon, a few more) with per-site credentials and attribution
Search & categorisation: shared search infrastructure, shared tagging, per-site result filtering
Analytics: Plausible, configured per-site
Hosting: one application, one database, one deployment pipeline
Why is Umbraco 17 a good fit for a multi-site affiliate platform?
Umbraco 17 is a better fit than v13 for this pattern for four reasons: compositions, the Management API, mature block editors, and a backoffice that scales. Umbraco has supported multi-site configurations for years; v17 is where the pieces stopped fighting us.
Composed document types compose better. The affiliate engine leans heavily on compositions - a _ListingCore with shared title, summary, rating, price-band, affiliate link fields, then per-type doc types that layer in the specifics. v17's property editor improvements and the polished compositions UI make that pattern genuinely maintainable, not just theoretically maintainable.
The Management API is the production API. We use the Management API (directly and via MCP) to provision new site roots, populate seed content, and sync listing data from affiliate partners. This is much cleaner than the v13 equivalent (which typically meant bespoke services or direct-DB work).
Block Grid and Block List at v17 maturity. Every site page (destination landing, category page, listicle) is assembled from a handful of blocks. Shared blocks, rendered with per-site theming. v13's Block List works; v17 gives us the layout composition we needed without writing a custom editor.
The backoffice scales to more content. We're looking at sites with 500-2000 listings each, spread across several sites. v17's backoffice handles the content tree performance better than v13 under that kind of load.
How does theming work across sites?
Theming on the engine is a three-level system: CSS variables, Razor partial overrides, and per-site services. The split matters because theming is the part most agencies get wrong in a multi-tenant platform. A theme as "a CSS file" is fine until a designer wants a site with different layout, different heading hierarchy, or different component behaviours. A theme as "a separate Razor project" is overkill and kills the "new site in half a day" promise.
Level 1 - CSS variables. Colour palette, typography, spacing, border-radius. Per-site, overrideable via a single CSS file that loads after the base. 90% of sites only need this level.
Level 2 - Razor partial overrides. If a site needs a different homepage layout, it drops a _Homepage.cshtml into its theme folder and the engine picks it up over the base. About 8% of sites need this.
Level 3 - Per-site services. If a site needs an integration the base doesn't have (a custom events API for a specific market, say), it registers a per-site service that the core affiliate engine resolves from the site's DI scope. Rare. About 2% of sites.
The split means most new brands are Level 1 only, and the engine doesn't get polluted with special cases.
What does a real site on the engine look like?
Bayr is the first public site on the engine: our tourism guide to the Isle of Man, live at bayr.im. It has:
188 places and attractions (mix of accommodation, food, activities, events)
Real-time weather feed from the Met Office
Tide tables from UKHO Admiralty
News aggregation from ManxRadio and 3FM
Affiliate integrations with Booking.com, GetYourGuide, Direct Ferries, Steam Packet, Amazon, Skiddle
Its own branding (navy/red, Playfair Display serif, compass motif)
Bayr uses Level 1 theming (colours, typography, logo) and Level 2 for the homepage (the island's compass-motif hero is specific to this site). Everything else is the base engine.
When a second site comes online - we're currently scoping entertainthekids.com as the next one - it'll be a Level 1 job. Same engine, same document types, different root node, different theme.
What is on the roadmap?
The roadmap is short: three things need work before we offer the engine to other affiliate operators.
A cleaner theme management UI. Right now a new theme is a folder commit. We want a backoffice admin that lets a non-developer pick a preset and tweak the colour palette without touching files.
Affiliate-source abstraction. We have integrations with seven providers. We want the integration layer to be a plugin model so new providers can be added without re-deploying the whole engine.
Per-site content staging. Right now all sites share a database with per-site content roots. That's fine for our operational model. If we were to let other operators license the engine as a managed platform, we'd need per-site DB separation and per-site deployment cadence.
Who is the affiliate engine for?
The affiliate engine is for anyone who needs the same content-driven site in several brand flavours: affiliate networks, tourism businesses with multiple locations, groups of local directories. We can license it, or we can run it as a managed service.
See Platforms on Simplepage.com for the commercial details, or get in touch for a scoping conversation. Bayr is the live-in-the-wild example.