Service Multisite
Network architecture, domain mapping, network plugins, object cache, backups. Built by a team that has run multisite networks at the 100+ site scale for over a decade.
<?php
// wp-config.php
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'network.example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
// Network-level object cache, keyed per blog
define( 'WP_CACHE_KEY_SALT', 'network.example.com:' );
define( 'WP_REDIS_PREFIX', 'wp_' . get_current_blog_id() . ':' );
// Per-site uploads under /wp-content/uploads/sites/{id}/
define( 'UPLOADBLOGSDIR', 'uploads/sites' );
define( 'NOBLOGREDIRECT', 'https://network.example.com' );
Why multisite
Franchise networks, agency client sites, multi-brand portfolios, university department sites, education networks, member intranets. One WordPress install, hundreds of sites, one admin team, one deployment pipeline. The architecture pays for itself the first time you push a security patch network-wide in five minutes instead of five days.
The catch is that multisite has sharp edges. Wrong topology choice locks you in for years. Cache misconfiguration burns the database. Plugin compatibility surprises break sites in production. We have hit those edges enough times to know how to avoid them.
What we build
Network topology picked deliberately. Object cache configured properly. Plugins network-aware from the first install. Domain mapping automated. Backups tested. Operations scripted.
01
Subdomain, subdirectory, or mapped domains. We pick the topology in discovery based on SEO strategy, content sharing requirements, and tenant isolation needs. Wrong topology forces a painful migration later.
Network scales to hundreds of sites without rework.
02
Plugins that detect network activation correctly, namespace database tables per blog, and use switch_to_blog() safely. No memory leaks, no cross-site data bleeds, no admin notices that show on the wrong dashboard.
Plugins behave consistently across every site.
03
Redis or Memcached configured with per-blog cache key salts. No cache pollution between sites. switch_to_blog() flushes the right cache groups. Object cache hit rate stays above 95% network-wide.
Network performance holds at 100+ sites.
04
Customer-facing sites with their own domains, all served from one WordPress install. Cloudflare or LiteSpeed for SSL termination at scale. Wildcard DNS, automated cert provisioning, no per-site SSL tickets.
New customer sites go live in minutes, not days.
05
Network-wide operations through WP-CLI. Plugin updates rolled out staggered. Search-replace across all sites. User cleanup, transient cleanup, autoload audit. We script the operations, you run them on a schedule.
Network maintenance scales without proportional ops time.
06
Network-wide backups that work. Per-site restores that do not break the network. Database snapshots that include the right tables. Tested restore drills before go-live, documented runbook for the on-call person.
Disaster recovery actually works when needed.
100+
WordPress plugins shipped, including network-aware enterprise plugins
Multisite tested. Network activation handled correctly. Source on WordPress.org and GitHub.
Process
01
One to two weeks. Topology decision (subdomain or subdirectory or mapped), plugin compatibility audit, performance baseline, backup strategy, SSL plan. Output is fixed price quote.
Architecture locked before code starts.
02
Four to twelve weeks depending on whether you are starting fresh or migrating from separate installs. Performance tuned at every milestone. Staging network available within seven days.
No surprises at cutover.
03
One to two weeks. DNS flip, SSL provisioned, monitoring active, runbook documented for ops team. We watch the network closely for thirty days.
Production starts stable.
Common questions
Multisite when sites share users, content, branding, or a centralized admin team. Separate installs when sites have totally different plugin stacks, different release cycles, or different security postures. Most multi-brand companies want multisite. Most reseller hosts want separate installs.
Subdomain (sub.example.com) for clear tenant separation, easier migration to standalone later, and simpler SEO segmentation. Subdirectory (example.com/sub/) for SEO consolidation under one domain. We pick the topology in discovery based on the SEO strategy.
Yes. WordPress core supports domain mapping out of the box since 4.5. We configure wildcard DNS, set up Cloudflare or LiteSpeed for SSL termination, and automate cert provisioning so new customer sites go live without manual cert work.
Most do. WooCommerce supports network activation but is happiest with per-site activation. BuddyPress runs as a network-wide social layer or per-site community. LearnDash runs per-site. We test plugin compatibility in discovery and document the activation strategy.
Staggered rollout through WP-CLI scripts. Update on a canary site first, monitor for errors, then roll out network-wide. Same pattern for theme updates and core updates. We document the rollout procedure as part of handover.
Multisite consultation and setup are scoped per project. Full multisite migrations from separate installs are scoped after discovery depending on site count and complexity. Network plugin development quoted separately. Discovery call is free.
Need multisite that scales?
Discovery call is free. Fixed-price quote within 48 hours. Projects are scope-dependent.