WordPress多站点网络搭建：子域名与子目录怎么选、域名映射与迁移注意点

发布时间：2026-09-16 12:32 更新时间：2026-09-16 12:32 阅读量：0

手里有好几个小站，每个都单独装一套 WordPress，升级插件要点开五个后台，主题改一处要复制五遍——这是不少站长在站点变多之后遇到的真实麻烦。WordPress 自带的 Multisite（多站点网络）就是为这种场景准备的：一套程序、一个数据库，网络里挂多个子站，插件和主题统一管理。但它不是装完就完事，搭建前要做的第一个决定——用子域名还是子目录——后面几乎决定了域名解析、SSL 证书、迁移方式的所有走向。这篇就把这个决定和后面的坑一次说清。

子域名与子目录：先看原理差异再动手

两种模式的本质区别在于每个子站的地址长什么样。子目录模式下，各个站点共享同一个主域名，靠路径区分，比如 example.com/shop、example.com/blog；子域名模式下，每个站点是独立的三级域名，比如 shop.example.com、blog.example.com。前台看起来只是地址不同，后端机制差别很大。

子目录模式对服务器最友好：只需要一个域名解析，一份 SSL 证书覆盖所有子站，Nginx 或 Apache 的伪静态规则也不用为每个子站单独写。它的限制在于所有子站共用同一个主域名，如果某个子站要独立备案、独立品牌形象，或者被搜索引擎当作同一个站点的不同栏目，就不太合适。

子域名模式则是每个子站都有独立的域名身份，搜索引擎会视为独立站点，适合面向不同地区、不同业务的站群。代价是你要为每个子域名做解析，通配符证书或逐个签发证书，服务器上的 server 块也要按子域名分别配置。另外要留意，子域名模式在网络创建时会要求主域名本身可访问，且不能是带 www 的形式，具体规则以官方文档为准。

选择建议很简单：子站之间内容关联强、只想省事，选子目录；子站要独立品牌、独立 SEO 定位，选子域名。这个选择在创建网络时就固定了，后期改起来很折腾，所以要一次想清楚。

搭建步骤与域名映射的真实配置

Multisite 不能在现有的普通站点上直接切换开关，稳妥做法是新建一个干净的 WordPress 再启用网络。先在 wp-config.php 中加入下面这行，位置要在 /* That's all, stop editing! */ 之前：

define( 'WP_ALLOW_MULTISITE', true );

然后登录后台，进入「工具 → 配置网络」，系统会检测当前环境并让你选择子域名或子目录。此时如果页面提示需要先停用全部插件，按提示操作即可。配置完成后，WordPress 会给出两段代码：一段加进 wp-config.php，一段替换掉 .htaccess 里的规则。用 Nginx 的机器不需要 .htaccess，要自己写 rewrite，下面是一份可参考的示例，路径与 fastcgi 参数请按自己环境改：

server {
    listen 80;
    server_name example.com *.example.com;
    root /www/wwwroot/example.com;
    index index.php index.html;

    if (!-e $request_filename) {
        rewrite ^/(.*)$ /index.php?/$1 last;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/tmp/php-cgi-74.sock;
        fastcgi_index index.php;
        include fastcgi.conf;
    }
}

子域名模式必须配 通配符 DNS 解析：在域名服务商处添加一条主机记录为 * 的 A 记录，指向服务器 IP，否则新开的子站会直接解析失败。SSL 证书方面，子目录模式一张普通证书就够；子域名模式要么申请通配符证书，要么在服务器上为每个子域名单独签发，具体以服务商和证书工具的官方文档为准。

如果网络里某个子站要绑定完全不同的独立域名，比如把 shop.example.com 换成 myshop.com，就要用域名映射插件，常见的有 WordPress 官方的 MU Domain Mapping 一类方案。做法是先把新域名的解析指到同一台服务器，再在插件里把站点 ID 与域名对应起来。这类插件对 WordPress 版本有要求，安装前先看插件页的兼容说明。

迁移时最容易踩的几个坑

多站点网络迁移比单站麻烦，因为它不是一张表，而是一整套共享表加多个子站的业务表。换服务器时，数据库必须整库导出导入，不能只导某个子站的前缀表，否则网络结构会散掉。迁移前先确认网络的表前缀，Multisite 的主表是 wp_blogs、wp_site、wp_sitemeta，子站数据表则按站点 ID 编号，例如 wp_2_posts、wp_3_posts，导出时一个都不能漏。

第二个坑是域名替换。整库导出后如果直接改域名，很容易破坏序列化数据。用 WP-CLI 的 search-replace 会更安全，它对序列化字段有处理：

wp search-replace 'old.com' 'new.com' --all-tables --precise --skip-columns=guid

加 --all-tables 是为了覆盖网络里所有子站的表；--skip-columns=guid 避免把文章 GUID 一起改掉，GUID 改动通常没有好处。执行前记得先备份数据库，命令的具体参数以 WP-CLI 官方文档为准。

第三个坑是主域名与站点地址。网络主站的 siteurl 和 home 存在 wp_options 里，子站的地址信息也存在各自选项表中，改完域名后要逐项核对后台「设置 → 常规」和「我的站点 → 管理网络 → 站点」里的地址是否一致。第四个坑是伪静态与证书：新服务器如果从 Apache 换到 Nginx，.htaccess 不会生效，必须按前面的示例重写规则；证书也要重新签发，子域名模式别漏掉通配符。

最后提醒一点，Multisite 的插件启用是网络级操作，某个子站要单独启用插件需要超级管理员在站点设置里授权。迁移后如果发现插件状态不对，先去网络后台检查一遍，而不是在子站后台反复点启用。

把上面这些理顺，多站点网络其实很省心：一套程序维护多个站点，升级和备份都只做一次。建议先在测试域名上把网络跑通，确认子域名解析、证书和伪静态都正常，再正式迁移生产数据。动手前做好整库备份，遇到拿不准的配置项，以 WordPress 官方文档和实际环境测试结果为准，别凭记忆改参数。

继续阅读