{"id":2131,"date":"2025-11-19T14:06:02","date_gmt":"2025-11-19T11:06:02","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/wordpress-multisite-on-a-vps-domain-mapping-ssl-and-performance-tuning\/"},"modified":"2025-11-19T14:06:02","modified_gmt":"2025-11-19T11:06:02","slug":"wordpress-multisite-on-a-vps-domain-mapping-ssl-and-performance-tuning","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-multisite-on-a-vps-domain-mapping-ssl-and-performance-tuning\/","title":{"rendered":"WordPress Multisite on a VPS: Domain Mapping, SSL and Performance Tuning"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Running multiple WordPress sites across different brands, languages, or regions often starts simply: one site per directory, one database per project. Then, someone asks for a new microsite, a regional clone, or a white\u2011label partner portal, and suddenly your server feels like a patchwork of separate installs, plugins, and users. This is exactly where WordPress Multisite on a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> shines. With a single WordPress codebase, you can host dozens\u2014or hundreds\u2014of sites while centralizing updates, users, themes, and plugins. On a virtual private server (VPS), you also gain full control over performance, SSL, and security hardening.<\/p>\n<p>In this guide, we\u2019ll walk through the full lifecycle of running WordPress Multisite on a VPS: how to plan your network architecture, configure domain mapping for separate domains, set up SSL correctly for every site, and tune your VPS so the whole network stays fast and stable. We\u2019ll base it on real\u2011world patterns we see every day at dchost.com, without drama and without magic tricks\u2014just practical steps you can reuse in your own environment.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_WordPress_Multisite_Belongs_on_a_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> Why WordPress Multisite Belongs on a VPS<\/a><ul><li><a href=\"#What_WordPress_Multisite_Actually_Does\"><span class=\"toc_number toc_depth_2\">1.1<\/span> What WordPress Multisite Actually Does<\/a><\/li><li><a href=\"#Why_a_VPS_Is_the_Natural_Home_for_Multisite\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Why a VPS Is the Natural Home for Multisite<\/a><\/li><\/ul><\/li><li><a href=\"#Planning_Your_Multisite_Architecture_on_a_VPS\"><span class=\"toc_number toc_depth_1\">2<\/span> Planning Your Multisite Architecture on a VPS<\/a><ul><li><a href=\"#Choose_Network_Type_Subdirectories_Subdomains_or_Separate_Domains\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Choose Network Type: Subdirectories, Subdomains, or Separate Domains<\/a><\/li><li><a href=\"#Domain_Strategy_for_a_Multisite_Network\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Domain Strategy for a Multisite Network<\/a><\/li><li><a href=\"#DNS_and_Nameserver_Planning\"><span class=\"toc_number toc_depth_2\">2.3<\/span> DNS and Nameserver Planning<\/a><\/li><\/ul><\/li><li><a href=\"#Installing_WordPress_Multisite_on_a_VPS\"><span class=\"toc_number toc_depth_1\">3<\/span> Installing WordPress Multisite on a VPS<\/a><ul><li><a href=\"#Prepare_the_Server_Stack\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Prepare the Server Stack<\/a><\/li><li><a href=\"#Standard_WordPress_Install\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Standard WordPress Install<\/a><\/li><li><a href=\"#Enable_Multisite_in_wp-configphp\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Enable Multisite in wp-config.php<\/a><\/li><\/ul><\/li><li><a href=\"#Domain_Mapping_for_WordPress_Multisite\"><span class=\"toc_number toc_depth_1\">4<\/span> Domain Mapping for WordPress Multisite<\/a><ul><li><a href=\"#Core_Concept_Network_URL_vs_Site_URL\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Core Concept: Network URL vs Site URL<\/a><\/li><li><a href=\"#StepbyStep_Domain_Mapping\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step\u2011by\u2011Step Domain Mapping<\/a><\/li><li><a href=\"#DNS_Patterns_for_Subdomain_Networks\"><span class=\"toc_number toc_depth_2\">4.3<\/span> DNS Patterns for Subdomain Networks<\/a><\/li><li><a href=\"#Nginx_Apache_Virtual_Host_Considerations\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Nginx \/ Apache Virtual Host Considerations<\/a><\/li><\/ul><\/li><li><a href=\"#SSL_for_Multisite_and_Mapped_Domains\"><span class=\"toc_number toc_depth_1\">5<\/span> SSL for Multisite and Mapped Domains<\/a><ul><li><a href=\"#Certificate_Options_for_Multisite\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Certificate Options for Multisite<\/a><\/li><li><a href=\"#ACME_Challenges_HTTP01_vs_DNS01\"><span class=\"toc_number toc_depth_2\">5.2<\/span> ACME Challenges: HTTP\u201101 vs DNS\u201101<\/a><\/li><li><a href=\"#Practical_SSL_Setup_Flow_on_a_VPS\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Practical SSL Setup Flow on a VPS<\/a><\/li><li><a href=\"#Handling_Mixed_Content_and_Redirects\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Handling Mixed Content and Redirects<\/a><\/li><\/ul><\/li><li><a href=\"#Performance_Tuning_WordPress_Multisite_on_a_VPS\"><span class=\"toc_number toc_depth_1\">6<\/span> Performance Tuning WordPress Multisite on a VPS<\/a><ul><li><a href=\"#PHPFPM_Pools_and_OPcache\"><span class=\"toc_number toc_depth_2\">6.1<\/span> PHP\u2011FPM Pools and OPcache<\/a><\/li><li><a href=\"#Database_MariaDBMySQL_Tuning\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Database (MariaDB\/MySQL) Tuning<\/a><\/li><li><a href=\"#Object_Caching_with_Redis_or_Memcached\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Object Caching with Redis or Memcached<\/a><\/li><li><a href=\"#FullPage_Caching_Nginx_Varnish_or_LiteSpeed\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Full\u2011Page Caching: Nginx, Varnish, or LiteSpeed<\/a><\/li><li><a href=\"#Microcaching_for_PHP_Bursts\"><span class=\"toc_number toc_depth_2\">6.5<\/span> Microcaching for PHP Bursts<\/a><\/li><li><a href=\"#CDN_and_Edge_Caching\"><span class=\"toc_number toc_depth_2\">6.6<\/span> CDN and Edge Caching<\/a><\/li><li><a href=\"#Disable_wp-cron_and_Use_Real_Cron_Jobs\"><span class=\"toc_number toc_depth_2\">6.7<\/span> Disable wp-cron and Use Real Cron Jobs<\/a><\/li><\/ul><\/li><li><a href=\"#Security_and_Maintenance_for_Multisite_on_a_VPS\"><span class=\"toc_number toc_depth_1\">7<\/span> Security and Maintenance for Multisite on a VPS<\/a><ul><li><a href=\"#WordPress_Hardening\"><span class=\"toc_number toc_depth_2\">7.1<\/span> WordPress Hardening<\/a><\/li><li><a href=\"#VPS-Level_Security\"><span class=\"toc_number toc_depth_2\">7.2<\/span> VPS-Level Security<\/a><\/li><li><a href=\"#Backups_and_Disaster_Recovery\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Backups and Disaster Recovery<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_All_Together_A_Calm_Repeatable_Multisite_Playbook\"><span class=\"toc_number toc_depth_1\">8<\/span> Putting It All Together: A Calm, Repeatable Multisite Playbook<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_WordPress_Multisite_Belongs_on_a_VPS\">Why WordPress Multisite Belongs on a VPS<\/span><\/h2>\n<p>Before touching config files, it\u2019s worth being clear about what WordPress Multisite is and why it fits naturally on a VPS rather than basic shared hosting.<\/p>\n<h3><span id=\"What_WordPress_Multisite_Actually_Does\">What WordPress Multisite Actually Does<\/span><\/h3>\n<p>WordPress Multisite lets you run multiple sites from a single WordPress installation and database. Think of it as a \u201cnetwork\u201d of sites that shares:<\/p>\n<ul>\n<li><strong>One codebase:<\/strong> core WordPress files, themes, and plugins are shared.<\/li>\n<li><strong>One user table:<\/strong> users can have roles on one or many sites.<\/li>\n<li><strong>Network\u2011wide updates:<\/strong> update plugins or WordPress once, apply everywhere.<\/li>\n<\/ul>\n<p>Each site still has its own posts, pages, settings, and even its own domain. This is powerful for agencies, multi\u2011brand companies, universities, franchises, and SaaS\u2011style setups.<\/p>\n<h3><span id=\"Why_a_VPS_Is_the_Natural_Home_for_Multisite\">Why a VPS Is the Natural Home for Multisite<\/span><\/h3>\n<p>Multisite pushes a server harder and in more complex ways than a single blog. A VPS gives you:<\/p>\n<ul>\n<li><strong>Dedicated resources:<\/strong> CPU, RAM and disk I\/O are reserved for you, so one noisy neighbour doesn\u2019t drag down your entire network.<\/li>\n<li><strong>Full control of the stack:<\/strong> choose Nginx or Apache, tune PHP\u2011FPM pools, MariaDB\/MySQL settings, and caching exactly for Multisite.<\/li>\n<li><strong>Flexible SSL and DNS:<\/strong> you can manage DNS records, ACME clients, and certificates for each mapped domain.<\/li>\n<li><strong>Scalability:<\/strong> you can scale vertically (more resources) or architect horizontally later if the network grows.<\/li>\n<\/ul>\n<p>If you\u2019re not sure how to size your VPS for your expected traffic and site count, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-laravel-ve-node-jsde-dogru-vps-kaynaklarini-nasil-secersin-cpu-ram-nvme-ve-bant-genisligi-rehberi\/\">choosing the right VPS resources for PHP applications<\/a> provides a good baseline for CPU, RAM, and storage planning.<\/p>\n<h2><span id=\"Planning_Your_Multisite_Architecture_on_a_VPS\">Planning Your Multisite Architecture on a VPS<\/span><\/h2>\n<p>Multisite is easiest when you plan the network before installation. A little architecture work now saves painful rewrites later.<\/p>\n<h3><span id=\"Choose_Network_Type_Subdirectories_Subdomains_or_Separate_Domains\">Choose Network Type: Subdirectories, Subdomains, or Separate Domains<\/span><\/h3>\n<p>WordPress Multisite supports three common patterns:<\/p>\n<ul>\n<li><strong>Subdirectories:<\/strong> example.com, example.com\/site1, example.com\/site2<\/li>\n<li><strong>Subdomains:<\/strong> example.com, site1.example.com, site2.example.com<\/li>\n<li><strong>Domain mapping (separate domains):<\/strong> example.com, brand1.com, brand2.net all living on the same Multisite<\/li>\n<\/ul>\n<p>For most serious use cases on a VPS, the decision is:<\/p>\n<ul>\n<li><strong>Subdomain network<\/strong> + wildcard DNS + optional domain mapping for some sites.<\/li>\n<li><strong>Domain\u2011mapped network<\/strong> where each site gets its own primary domain for branding and SEO.<\/li>\n<\/ul>\n<p>Subdirectories are simpler on paper but can complicate caching, security headers, and SEO in multi\u2011language or multi\u2011brand scenarios. Domain mapping gives you maximum flexibility and isolates SEO signals by domain.<\/p>\n<h3><span id=\"Domain_Strategy_for_a_Multisite_Network\">Domain Strategy for a Multisite Network<\/span><\/h3>\n<p>If you\u2019re building multilingual or multi\u2011region sites, it\u2019s worth stepping back to think about domains and SEO. Will you use:<\/p>\n<ul>\n<li>Separate ccTLDs (example.de, example.fr)<\/li>\n<li>Subdomains (de.example.com, fr.example.com)<\/li>\n<li>Subdirectories (example.com\/de\/, example.com\/fr\/)<\/li>\n<\/ul>\n<p>Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hreflangi-dogru-kurmanin-sirlari-cctld-alt-dizin-alt-alan-ve-x-default-ile-uluslararasi-seoyu-rayina-oturt\/\">hreflang and international SEO architectures<\/a> is a great companion when deciding how to structure a global Multisite network.<\/p>\n<h3><span id=\"DNS_and_Nameserver_Planning\">DNS and Nameserver Planning<\/span><\/h3>\n<p>Before you even install WordPress, align your DNS and nameserver strategy:<\/p>\n<ul>\n<li>Decide whether to use registrar DNS, external DNS, or your own private nameservers.<\/li>\n<li>Plan A\/AAAA records for the main domain and mapped domains.<\/li>\n<li>If using subdomain Multisite, prepare <strong>wildcard DNS<\/strong> (*.example.com).<\/li>\n<\/ul>\n<p>If you run your own DNS on the VPS or in your infrastructure, you may want to set up private nameservers and glue records. Our step\u2011by\u2011step guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ozel-ad-sunucusu-ve-glue-record-nasil-kurulur-kendi-dnsine-adim-adim-yolculuk\/\">configuring private nameservers and glue records<\/a> walks through that process in detail.<\/p>\n<p>For a refresher on record types (A, AAAA, CNAME, MX, TXT, CAA and more), bookmark our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/\">explaining DNS records like a friend<\/a>.<\/p>\n<h2><span id=\"Installing_WordPress_Multisite_on_a_VPS\">Installing WordPress Multisite on a VPS<\/span><\/h2>\n<p>Once your VPS is provisioned and DNS is pointing at it, the next step is to install WordPress and enable Multisite. The exact commands differ between distributions, but the overall flow is consistent.<\/p>\n<h3><span id=\"Prepare_the_Server_Stack\">Prepare the Server Stack<\/span><\/h3>\n<p>On your VPS you will typically run:<\/p>\n<ul>\n<li><strong>Web server:<\/strong> Nginx or Apache<\/li>\n<li><strong>PHP\u2011FPM:<\/strong> PHP 8.x with required extensions (mysqli, mbstring, curl, json, xml, gd\/imagick, etc.)<\/li>\n<li><strong>Database:<\/strong> MariaDB or MySQL<\/li>\n<\/ul>\n<p>Our WordPress\u2011focused tuning guide, <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">The Server-Side Secrets That Make WordPress Fly<\/a>, covers PHP\u2011FPM, OPcache, Redis and MySQL tuning in depth and pairs nicely with this Multisite setup.<\/p>\n<h3><span id=\"Standard_WordPress_Install\">Standard WordPress Install<\/span><\/h3>\n<ol>\n<li>Create a database and a user with a strong password.<\/li>\n<li>Download the latest WordPress package and extract it into your web root.<\/li>\n<li>Configure your virtual host (Nginx server block or Apache vhost) to point to this directory.<\/li>\n<li>Complete the standard WordPress installer via the browser.<\/li>\n<\/ol>\n<p>At this stage you should have a normal single\u2011site WordPress installation reachable over HTTP\/HTTPS on the main domain.<\/p>\n<h3><span id=\"Enable_Multisite_in_wp-configphp\">Enable Multisite in wp-config.php<\/span><\/h3>\n<p>To convert your single site to a Multisite network:<\/p>\n<ol>\n<li>Edit <code>wp-config.php<\/code> and add above the line that reads <code>\/* That's all, stop editing! Happy publishing. *\/<\/code>:<\/li>\n<\/ol>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">define( 'WP_ALLOW_MULTISITE', true );\n<\/code><\/pre>\n<ol start=\"2\">\n<li>Refresh the WordPress admin. Go to <strong>Tools &gt; Network Setup<\/strong>.<\/li>\n<li>Choose <strong>Subdomains<\/strong> or <strong>Subdirectories<\/strong> based on your plan.<\/li>\n<li>Follow the on\u2011screen instructions to add more lines to <code>wp-config.php<\/code> and update <code>.htaccess<\/code> (Apache) or Nginx rules.<\/li>\n<\/ol>\n<p>After logging back in, you\u2019ll see the <strong>My Sites &gt; Network Admin<\/strong> menu, where you manage the entire network.<\/p>\n<h2><span id=\"Domain_Mapping_for_WordPress_Multisite\">Domain Mapping for WordPress Multisite<\/span><\/h2>\n<p>Modern WordPress no longer needs a separate \u201cdomain mapping\u201d plugin. Everything is handled by core using the <strong>Site Address (URL)<\/strong> field for each site.<\/p>\n<h3><span id=\"Core_Concept_Network_URL_vs_Site_URL\">Core Concept: Network URL vs Site URL<\/span><\/h3>\n<p>When you create a new site from Network Admin, you define:<\/p>\n<ul>\n<li><strong>Site domain\/path:<\/strong> e.g. site2.example.com or \/site2<\/li>\n<li><strong>Site title<\/strong><\/li>\n<li><strong>Admin email<\/strong><\/li>\n<\/ul>\n<p>This creates the site using the <strong>network\u2019s default URL structure<\/strong>. Then you \u201cmap\u201d a real domain to it by changing the <strong>Site Address (URL)<\/strong> in the site\u2019s settings.<\/p>\n<h3><span id=\"StepbyStep_Domain_Mapping\">Step\u2011by\u2011Step Domain Mapping<\/span><\/h3>\n<ol>\n<li><strong>Create the site<\/strong> in Network Admin using a placeholder URL (subdomain or subdirectory) that works.<\/li>\n<li><strong>Point the real domain\u2019s DNS<\/strong> to your VPS IP (A\/AAAA record):\n<ul>\n<li><code>brand1.com -&gt; 203.0.113.10<\/code><\/li>\n<li><code>www.brand1.com -&gt; 203.0.113.10<\/code> (often via CNAME to brand1.com)<\/li>\n<\/ul>\n<\/li>\n<li>In Network Admin, go to <strong>Sites &gt; All Sites<\/strong>, find the site, click <strong>Edit<\/strong>.<\/li>\n<li>Change <strong>Site Address (URL)<\/strong> from something like <code>https:\/\/site1.example.com<\/code> to <code>https:\/\/brand1.com<\/code>.<\/li>\n<li>Save. WordPress will now treat <code>https:\/\/brand1.com<\/code> as the primary URL for that site.<\/li>\n<\/ol>\n<p>Repeat for each mapped domain. Under the hood, all sites still live in one database and codebase; you\u2019re simply telling WordPress which domain is attached to which site.<\/p>\n<h3><span id=\"DNS_Patterns_for_Subdomain_Networks\">DNS Patterns for Subdomain Networks<\/span><\/h3>\n<p>If your base network uses subdomains, you\u2019ll typically set:<\/p>\n<ul>\n<li><code>A   example.com      203.0.113.10<\/code><\/li>\n<li><code>A   *.example.com    203.0.113.10<\/code>  (wildcard)<\/li>\n<\/ul>\n<p>The wildcard covers any subsite you create: <code>en.example.com<\/code>, <code>shop.example.com<\/code>, <code>blog.example.com<\/code>, etc., without needing to add separate DNS records every time.<\/p>\n<p>For mapped domains (brand1.com, brand2.net), you add separate A\/AAAA records pointing to the same VPS. From WordPress\u2019s perspective, they\u2019re just additional hostnames routed to the same web root.<\/p>\n<h3><span id=\"Nginx_Apache_Virtual_Host_Considerations\">Nginx \/ Apache Virtual Host Considerations<\/span><\/h3>\n<p>For domain\u2011mapped Multisite on a single VPS:<\/p>\n<ul>\n<li>You usually have <strong>one vhost\/server block<\/strong> that listens on 80\/443 and serves the same document root.<\/li>\n<li>That virtual host uses <code>server_name<\/code> (Nginx) or <code>ServerAlias<\/code> (Apache) to match all hostnames.<\/li>\n<\/ul>\n<p>Example (Nginx snippet):<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">server {\n    listen 80;\n    server_name example.com *.example.com brand1.com brand2.net;\n    root \/var\/www\/example.com\/public;\n    # ... PHP and rewrite rules ...\n}\n<\/code><\/pre>\n<p>Later, when we add SSL, we\u2019ll extend this configuration with <code>listen 443 ssl<\/code> and certificate directives for all domains.<\/p>\n<h2><span id=\"SSL_for_Multisite_and_Mapped_Domains\">SSL for Multisite and Mapped Domains<\/span><\/h2>\n<p>SSL is where many Multisite setups become fragile. You have multiple hostnames, possibly wildcards plus individual domains, and a mix of HTTP challenges. The key is to plan your certificate strategy upfront.<\/p>\n<h3><span id=\"Certificate_Options_for_Multisite\">Certificate Options for Multisite<\/span><\/h3>\n<p>You essentially have four patterns:<\/p>\n<ul>\n<li><strong>Single certificate for base domain only:<\/strong> covers example.com and maybe www.example.com. Not enough for mapped domains.<\/li>\n<li><strong>Wildcard certificate:<\/strong> <code>*.example.com<\/code> covers all subdomains of example.com but <em>not<\/em> brand1.com.<\/li>\n<li><strong>SAN (multi\u2011domain) certificate:<\/strong> one cert that lists several domains, e.g. example.com, brand1.com, brand2.net.<\/li>\n<li><strong>Separate certificates per domain:<\/strong> one cert for each mapped domain.<\/li>\n<\/ul>\n<p>On a growing Multisite, the most flexible pattern is usually:<\/p>\n<ul>\n<li>Wildcard certificate for the network\u2019s base domain (if you use subdomains).<\/li>\n<li>Individual certificates per mapped domain, automated via ACME (Let\u2019s Encrypt\/ZeroSSL, etc.).<\/li>\n<\/ul>\n<p>If you\u2019re unsure how to choose between DV, OV, EV, and wildcard SSL, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dv-ov-ev-ve-wildcard-ssl-arasinda-kaybolmadan-e%e2%80%91ticaret-ve-saaste-hangi-sertifika-ne-zaman\/\">selecting the right SSL certificate type<\/a> walks through real\u2011world scenarios for e\u2011commerce and SaaS.<\/p>\n<h3><span id=\"ACME_Challenges_HTTP01_vs_DNS01\">ACME Challenges: HTTP\u201101 vs DNS\u201101<\/span><\/h3>\n<p>Automatic SSL usually relies on the ACME protocol. You\u2019ll need to decide how certificates are validated:<\/p>\n<ul>\n<li><strong>HTTP\u201101 challenge:<\/strong> CA hits <code>http:\/\/yourdomain\/.well-known\/acme-challenge\/...<\/code> on port 80. Simple but requires the domain to already resolve correctly to your VPS.<\/li>\n<li><strong>DNS\u201101 challenge:<\/strong> CA checks a special TXT record in DNS. This is required for wildcard certificates and is very handy when issuing certificates for many tenant domains.<\/li>\n<\/ul>\n<p>We\u2019ve written a deep dive on <a href=\"https:\/\/www.dchost.com\/blog\/en\/acme-challenge-turleri-derinlemesine-http%e2%80%9101-dns%e2%80%9101-ve-tls%e2%80%91alpn%e2%80%9101-ne-zaman-hangisi\/\">HTTP-01 and DNS-01 ACME challenges<\/a> and another playbook on <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-wildcard-ssl-otomasyonu-dns-01-ile-cpanel-plesk-ve-nginxte-zahmetsiz-kurulum-ve-yenileme-nasil-yapilir\/\">Let\u2019s Encrypt wildcard SSL automation<\/a>; both are directly applicable to Multisite networks on a VPS.<\/p>\n<h3><span id=\"Practical_SSL_Setup_Flow_on_a_VPS\">Practical SSL Setup Flow on a VPS<\/span><\/h3>\n<ol>\n<li><strong>Get basic HTTPS running<\/strong> for the base domain using a DV certificate (ACME HTTP\u201101 is usually simplest for the first cert).<\/li>\n<li><strong>Add wildcard SSL<\/strong> for <code>*.example.com<\/code> with DNS\u201101 if you use a subdomain network.<\/li>\n<li><strong>Automate per\u2011domain DV certificates<\/strong> for each mapped domain (brand1.com, brand2.net). Many ACME clients can handle multiple certs with renewal hooks.<\/li>\n<li><strong>Configure SNI<\/strong> (Server Name Indication), which is standard in modern web servers, so different certificates can be served per hostname on the same IP.<\/li>\n<\/ol>\n<p>Don\u2019t forget to set correct CAA records if you lock your domains to specific CAs. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/caa-kayitlari-derinlemesine-neden-nasil-ve-ne-zaman-coklu%e2%80%91caya-gecmelisin\/\">CAA records and multi\u2011CA strategies<\/a> covers how to avoid accidental certificate issuance failures.<\/p>\n<h3><span id=\"Handling_Mixed_Content_and_Redirects\">Handling Mixed Content and Redirects<\/span><\/h3>\n<p>Once HTTPS is in place, ensure:<\/p>\n<ul>\n<li>All sites force HTTPS (301 redirect from HTTP to HTTPS).<\/li>\n<li>WordPress <strong>Site Address (URL)<\/strong> for each site uses <code>https:\/\/<\/code>.<\/li>\n<li>Themes and plugins don\u2019t hard\u2011code <code>http:\/\/<\/code> URLs in templates.<\/li>\n<\/ul>\n<p>If you face mixed\u2011content warnings (some assets loading over HTTP), search\/replace old HTTP URLs in the database and check plugin configurations. Multisite amplifies small configuration mistakes, so it pays to fix mixed content thoroughly before scaling out.<\/p>\n<h2><span id=\"Performance_Tuning_WordPress_Multisite_on_a_VPS\">Performance Tuning WordPress Multisite on a VPS<\/span><\/h2>\n<p>Now to the part that keeps your network fast as you add sites and traffic: tuning the VPS stack. The good news: most tuning you\u2019d do for a single high\u2011traffic WordPress site also applies to Multisite; you just need to size things for the aggregate load.<\/p>\n<h3><span id=\"PHPFPM_Pools_and_OPcache\">PHP\u2011FPM Pools and OPcache<\/span><\/h3>\n<p>On a Multisite network, PHP workers serve all sites. Make sure:<\/p>\n<ul>\n<li><strong>pm.max_children<\/strong> is sized for your RAM and concurrency. Too low and users queue; too high and you swap.<\/li>\n<li><strong>pm.max_requests<\/strong> is set to a reasonable number (e.g. 500\u20131000) to avoid memory leaks.<\/li>\n<li><strong>opcache.memory_consumption<\/strong> is large enough to hold your core, themes, and plugins once; Multisite doesn\u2019t multiply code size, which is a big win.<\/li>\n<\/ul>\n<p>Our server\u2011side tuning article mentioned earlier goes into specific starting values and measurement techniques.<\/p>\n<h3><span id=\"Database_MariaDBMySQL_Tuning\">Database (MariaDB\/MySQL) Tuning<\/span><\/h3>\n<p>Multisite uses more tables per network but the same engine under the hood. Focus on:<\/p>\n<ul>\n<li><strong>innodb_buffer_pool_size:<\/strong> big enough to keep hot indexes and data in RAM.<\/li>\n<li><strong>query_cache:<\/strong> disabled on modern MariaDB\/MySQL versions in favour of good indexing and app\u2011level caching.<\/li>\n<li><strong>Slow query logging:<\/strong> identify problematic plugins or queries across the network.<\/li>\n<\/ul>\n<p>When WooCommerce or other heavy plugins join the network, you can reuse many of the ideas from our <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-icin-mysql-innodb-tuning-kontrol-listesi-buffer-pool-indeksleme-ve-slow-query-analizi-nasil-akillica-yapilir\/\">WooCommerce MySQL\/InnoDB tuning checklist<\/a>.<\/p>\n<h3><span id=\"Object_Caching_with_Redis_or_Memcached\">Object Caching with Redis or Memcached<\/span><\/h3>\n<p>For any serious Multisite installation, a persistent object cache is almost mandatory. Without it, every page build will hammer the database with repeated option, meta, and term queries across many sites.<\/p>\n<ul>\n<li>Install Redis or Memcached on the VPS.<\/li>\n<li>Use a well\u2011maintained WordPress object cache drop\u2011in (e.g. a Redis object cache plugin).<\/li>\n<li>Set a clear TTL strategy and memory limit (don\u2019t let cache eviction become random chaos).<\/li>\n<\/ul>\n<p>Our comparison of <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-redis-mi-memcached-mi-kalici-nesne-onbellegi-ttl-ve-eviction-ayarlarini-ne-zaman-nasil-yaparsin\/\">Redis vs Memcached for WordPress<\/a> explains how to choose and tune TTL and eviction for busy sites, which translates directly to Multisite setups.<\/p>\n<h3><span id=\"FullPage_Caching_Nginx_Varnish_or_LiteSpeed\">Full\u2011Page Caching: Nginx, Varnish, or LiteSpeed<\/span><\/h3>\n<p>Full\u2011page caching is where the biggest performance gains lie, especially when many sites are essentially CMS or marketing pages with limited personalization. Options include:<\/p>\n<ul>\n<li><strong>Nginx FastCGI cache<\/strong> in front of PHP\u2011FPM.<\/li>\n<li><strong>Varnish<\/strong> as a dedicated caching proxy.<\/li>\n<li><strong>LiteSpeed Cache<\/strong> if you run LiteSpeed\/OpenLiteSpeed.<\/li>\n<\/ul>\n<p>Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpresste-tam-sayfa-onbellekleme-nasil-kurulur-nginx-fastcgi-cache-varnish-ve-litespeed-cache-ile-woocommercee-nazikce-dokunmak\/\">full-page caching for WordPress without breaking WooCommerce<\/a> shows real configurations for each stack. On Multisite, you\u2019ll pay extra attention to cache keys (host + path) so each domain\u2019s pages stay isolated and correctly invalidated.<\/p>\n<h3><span id=\"Microcaching_for_PHP_Bursts\">Microcaching for PHP Bursts<\/span><\/h3>\n<p>For busy login\u2011heavy networks or dashboards, you can even use 1\u20135 second microcaches at the reverse proxy layer to absorb traffic spikes. This is especially helpful when many users hit the same page (e.g. a popular blog post or landing page) at once. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nginx-mikro-onbellekleme-ile-php-uygulamalarini-ucurmak-1-5-sn-cache-bypass-ve-purge-ne-zaman-nasil\/\">Nginx microcaching for PHP apps<\/a> demonstrates how this pattern feels in practice.<\/p>\n<h3><span id=\"CDN_and_Edge_Caching\">CDN and Edge Caching<\/span><\/h3>\n<p>A CDN layered in front of your VPS can dramatically improve global performance by caching static assets (and sometimes HTML) closer to users. For a Multisite network:<\/p>\n<ul>\n<li>All mapped domains can use the same CDN provider, each with its own cache rules.<\/li>\n<li>Use consistent <code>Cache-Control<\/code> headers and asset fingerprinting so browsers and CDNs can cache aggressively.<\/li>\n<li>Be careful with HTML caching on logged\u2011in admin and e\u2011commerce flows.<\/li>\n<\/ul>\n<p>If you want a deeper playbook on headers and cache behaviour, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/nereden-baslamaliyiz-bir-css-dosyasinin-pesinde\/\">cache-control, ETag, and asset fingerprinting<\/a>.<\/p>\n<h3><span id=\"Disable_wp-cron_and_Use_Real_Cron_Jobs\">Disable wp-cron and Use Real Cron Jobs<\/span><\/h3>\n<p>On a Multisite with many sites, <code>wp-cron.php<\/code> running on every page load becomes both a performance cost and a source of unpredictability. On a VPS, you have the luxury of using real cron:<\/p>\n<ul>\n<li>Disable <code>wp-cron.php<\/code> from running on every request.<\/li>\n<li>Set up a system cron job to call <code>wp-cron.php<\/code> on a fixed schedule (e.g. every 5 minutes).<\/li>\n<\/ul>\n<p>This makes scheduled tasks (publishing, emails, cleanups) far more reliable and reduces page load times. We\u2019ve written a dedicated guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpresste-wp-cron-devre-disi-birakma-ve-gercek-cron-job-kurulumu\/\">disabling wp-cron and using real cron jobs on cPanel and VPS<\/a>, which applies perfectly to Multisite networks.<\/p>\n<h2><span id=\"Security_and_Maintenance_for_Multisite_on_a_VPS\">Security and Maintenance for Multisite on a VPS<\/span><\/h2>\n<p>A Multisite network concentrates many sites into one platform. This is operationally efficient but also raises the stakes: a misconfiguration, vulnerable plugin, or compromised admin account can affect many brands at once. A few disciplines go a long way.<\/p>\n<h3><span id=\"WordPress_Hardening\">WordPress Hardening<\/span><\/h3>\n<p>At the application level:<\/p>\n<ul>\n<li>Use strong, unique passwords and enforce 2FA for network admins.<\/li>\n<li>Limit the number of super admins; most work can be done as site admins.<\/li>\n<li>Harden file permissions, disable file editing in the dashboard, and restrict access to <code>wp-admin<\/code> where possible.<\/li>\n<li>Review plugins and themes regularly; avoid abandoned or poorly maintained code.<\/li>\n<\/ul>\n<p>Our <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenlik-sertlestirme-kontrol-listesi-dosya-izinleri-salt-keys-xml-rpc-ufw-fail2ban-nasil-tatli-tatli-kurulur\/\">WordPress hardening checklist<\/a> walks through concrete file permission, salt keys, XML\u2011RPC, UFW, and Fail2ban configurations you can apply on your VPS.<\/p>\n<h3><span id=\"VPS-Level_Security\">VPS-Level Security<\/span><\/h3>\n<p>On the VPS itself, treat the host as production\u2011critical infrastructure:<\/p>\n<ul>\n<li>Lock down SSH (key\u2011based auth, non\u2011default port, Fail2ban, or similar).<\/li>\n<li>Run a host firewall (UFW or nftables) limiting exposed ports.<\/li>\n<li>Keep the OS, PHP, and database packages updated.<\/li>\n<li>Monitor logs and set up basic alerting for unusual activity.<\/li>\n<\/ul>\n<p>Our calm guide to <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">securing a VPS server<\/a> outlines a realistic hardening path that fits nicely around a Multisite network.<\/p>\n<h3><span id=\"Backups_and_Disaster_Recovery\">Backups and Disaster Recovery<\/span><\/h3>\n<p>Because Multisite concentrates many sites into one database and file tree, backups are non\u2011negotiable:<\/p>\n<ul>\n<li>Automate daily offsite backups (database + wp-content).<\/li>\n<li>Use retention policies (e.g. 7 daily, 4 weekly, 3 monthly backups).<\/li>\n<li>Test restore procedures on a staging VPS so you\u2019re not learning during an incident.<\/li>\n<\/ul>\n<p>Our guide to the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3\u20112\u20111 backup strategy<\/a> explains how to structure backups on VPS environments so a single failure doesn\u2019t wipe out your entire network.<\/p>\n<h2><span id=\"Putting_It_All_Together_A_Calm_Repeatable_Multisite_Playbook\">Putting It All Together: A Calm, Repeatable Multisite Playbook<\/span><\/h2>\n<p>Running WordPress Multisite on a VPS can look intimidating on paper: many domains, one codebase, multiple <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s, caching layers, and a shared database. In practice, once you break it into steps, it becomes a calm, repeatable pattern you can reuse for every new network you deploy.<\/p>\n<p>You start by choosing a VPS plan with enough headroom and designing a clear domain and DNS strategy. Then you install WordPress, enable Multisite, and set up domain mapping from each brand\u2019s domain to its corresponding site. With SSL, you define a certificate strategy\u2014wildcard for subdomains, per\u2011domain DV for mapped sites\u2014and automate issuance and renewal. Finally, you tune the stack with PHP\u2011FPM, OPcache, a persistent object cache, and full\u2011page caching, so your network stays responsive even as you add new sites and traffic grows.<\/p>\n<p>At dchost.com, we see the same pattern again and again: once teams move their Multisite network onto a properly tuned VPS, they stop fighting the platform and start focusing on content, features, and growth. If you\u2019re planning a new Multisite rollout or want to consolidate a sprawl of separate installs, this is the perfect time to design it cleanly on a VPS. And if you\u2019d like a second pair of eyes on your architecture, our team is here to help you choose the right VPS, SSL approach, and tuning strategy for your WordPress Multisite network.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Running multiple WordPress sites across different brands, languages, or regions often starts simply: one site per directory, one database per project. Then, someone asks for a new microsite, a regional clone, or a white\u2011label partner portal, and suddenly your server feels like a patchwork of separate installs, plugins, and users. This is exactly where WordPress [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2132,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-2131","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2131","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2131"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2131\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2132"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2131"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2131"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2131"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}