Are you maintaining ten websites that differ only by a logo and a language?

Every site in the network has its own set of tables, its own media, its own menus and its own roles, so an editor on one site never sees the content of the others. Only the code is shared: core, themes and plugins are updated in one place for every site at once. The network administrator gets an overview that separate installations never produce, because a single list shows which site runs which version and where each feature is enabled. That overview is the main reason multisite already pays off at around five sites.

• Content, media and users separated per site
• Core and plugin updates once for the whole network
• An overview of every site in one place
• Network administrator and per-site administrator roles
• One hosting account and one backup instead of ten

Shared code does not mean identical sites. The theme carries site-level settings, so colours, logo, typography and part of the layout differ depending on whose site it is. Plugins can be activated network-wide or only for a single site, so a feature one market needs does not weigh down the rest. I handle variation in code with sensible defaults rather than by copying the theme, because a copied theme is exactly the debt multisite exists to prevent. A new feature is then written once and available everywhere.

• Colours, logo and typography at site level
• Plugins active network-wide or for one site only
• Variation in code, not in a copied theme
• A new feature written once for the whole network
• A consistent base under different visual identities

A network can run on subdirectories, on subdomains or on entirely separate domains, which matters for an international brand. Each market gets its own country domain, its own language, its own prices and its own contacts, while sharing the product structure and the design. The countries can be linked with language annotations so search engines understand which version belongs to which audience. There is an organisational benefit too: the local team manages its own content with no access to other markets, while headquarters changes templates for everyone at once.

• Subdirectories, subdomains or separate domains
• A country domain, language and pricing per market
• Language versions linked for search engines
• Local teams see only their own content
• One central template change for the whole network

The strongest property of a multisite platform is that a new site does not begin as a blank page. I prepare a template site with structure, sample content and settings, and a new site is created as a clone of it that only needs the real copy filled in. The same mechanism serves as staging: a copy of a live site inside the same network where a rebuild can be tried safely while the original keeps running. This is how I operate a platform of template demo sites, where a new demo goes up in minutes instead of half a day.

• A new site as a clone of a template site
• Sample content and structure prepared in advance
• A staging copy inside the same network
• Launching a new site in minutes, not a day
• The same process for demos and for client sites

I do not recommend multisite everywhere. If the sites differ functionally, follow different lifecycles or are meant to be maintained by independent suppliers, keeping them separate is cleaner, because a bug in shared code otherwise takes the whole network down at once. Likewise, one very busy shop inside a network can slow the others down. Multisite pays off where the sites are variations of the same thing. I work at 40 EUR per hour including VAT; setting up a network with a shared theme is usually 15 to 40 hours, and migrating existing sites into it is quoted separately.

• Functionally different sites are better kept apart
• Shared code means shared risk
• Best where sites are variations of one template
• Network setup roughly 15 to 40 hours
• 40 EUR per hour including VAT, migrations quoted separately