on October 15, 2026
WordPress Multisite gets pitched as “one WordPress install running several sites” and that description is accurate right up until you try to do something that assumes each site is independent. I work on one – a network of four sites sharing a single filesystem – and most of the surprises are not in the WordPress admin. They’re in what “shared” actually means once you start building.
The filesystem is genuinely shared, not just the database
Multisite’s marketing focuses on the shared user table and shared plugin activation – true, and mostly harmless. What catches people off guard is that the document root itself is shared too. Any static file you place at the server’s root – a literal robots.txt, a literal llms.txt, an image, anything not routed through WordPress – gets served identically to every domain on the network. There’s no per-site document root to drop a file into.
This isn’t a hypothetical: it’s the exact reason a plain static file doesn’t work for something like an llms.txt route (I’ve written about the fix for that specifically) – and it applies to anything else you’d normally just “put a file on the server” to solve. If it needs to differ per site, it has to be a dynamic WordPress route, generated by code that only runs while that site’s theme or plugin is active.
Confirm assumptions before you rely on them
When I needed to know whether something was safe to build as a static file, I didn’t guess – I compared how Yoast SEO already handles a similar problem. Yoast generates robots.txt dynamically, per site, specifically because a static file wouldn’t work correctly on Multisite. That’s a reliable signal: if a mature plugin that supports Multisite went to the trouble of generating something dynamically instead of shipping a static default, there’s usually a Multisite-specific reason, and it’s worth finding out what it is before you build the simpler version.
Theme-scoped code is your safety boundary
The practical takeaway: code you put in a specific site’s functions.php only runs while that site’s theme is active. That’s the boundary that keeps a fix for one site from silently affecting the others – not the network admin settings, not file permissions, just which theme’s code is currently loaded. Before adding anything network-facing – a custom rewrite rule, a redirect, a scheduled task – it’s worth explicitly asking whether it’s meant to be site-specific or network-wide, and building it accordingly. The two look identical in a code editor and behave very differently in production.
Plugin and theme deactivation, not deletion
On a single-site install, deleting an unused plugin or theme is routine housekeeping. On Multisite, a theme or plugin might be active on a sibling site even if it looks unused from the one you’re working on – deactivate, don’t delete, unless you’ve actually confirmed nothing else on the network depends on it. This is a small habit that costs nothing most of the time and prevents a genuinely bad afternoon the one time it matters.
Is Multisite the right call in the first place?
It’s a good fit when the sites genuinely share infrastructure needs – same team managing updates, similar plugin requirements, willingness to accept that a network-wide plugin vulnerability affects everyone at once. It’s a poor fit when sites need to scale independently, when different teams manage different sites and shouldn’t have visibility into each other’s, or when the “shared everything” model creates more coordination overhead than it saves. If you’re deciding whether to set one up, that tradeoff – shared operational simplicity versus shared blast radius – is the real question, more than any specific technical feature.
Working on an existing Multisite network
If you’ve inherited a WordPress Multisite setup and need something built that respects its constraints properly – rather than something that happens to work in testing and breaks a sibling site in production – get in touch.