Service Multisite

WordPress multisite that survives at network scale.

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.

WordPress agency since 2013, 100+ plugins shipped
wp-config.php
wp-config.php php
    
      
          
          <?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

Multisite is the right answer when one team runs many sites.

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

Multisite networks that scale without surprises.

Network topology picked deliberately. Object cache configured properly. Plugins network-aware from the first install. Domain mapping automated. Backups tested. Operations scripted.

01

Network architecture done right

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

Network plugins with proper context

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

Object cache keyed per site

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

Per-site domain mapping

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

WP-CLI scripted operations

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

Backup and restore strategy

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

How a multisite engagement runs.

01

Discovery

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

Build or migrate

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

Cutover and document

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

Frequently asked

  1. When should we use multisite vs separate WordPress installs?

    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.

  2. Subdomain or subdirectory?

    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.

  3. Can we map customer domains to network sites?

    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.

  4. Do plugins like WooCommerce, LearnDash, BuddyPress work on multisite?

    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.

  5. How do we handle network-wide plugin updates?

    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.

  6. What does it cost?

    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?

Tell us what you want to build.

Discovery call is free. Fixed-price quote within 48 hours. Projects are scope-dependent.