三年前，一个客户在周四下午给我打电话，声音很急促。他们把 Drupal 转 WordPress 的工作交给了一家廉价的开发公司，网站周五上线，周一有机流量就下降了 67%。没了。六年的 SEO 积累，就这样……蒸发了。没有重定向。数千个损坏的 URL。谷歌的爬虫预算也用尽了。Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.
关键要点：Drupal 到 WordPress 迁移失败的原因是 URL 映射和分类法转换，而非 CMS 本身的切换；需要提供完整的重定向映射表并迁移元数据以保持排名。Drupal to WordPress migrations fail on URL mapping and taxonomy translation, not the CMS swap; ship a complete redirect map and transport metadata to keep rankings.
我已经处理过不计其数次这样的混乱情况。在 Seahawk Media 处理了 12,000+ 次迁移后，我可以有把握地告诉你：从 Drupal 到 WordPress 的技术迁移实际上是最简单的部分。SEO 保留才是一切出问题的地方——也是完全不必出问题的地方。Seahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong -- and where it absolutely doesn't have to.
这是我遵循的策略。每一次都是。
---
为什么 Drupal 到 WordPress 的迁移是 SEO 地雷区
Drupal和WordPress生成URL的方式不同。Drupal的默认路径系统，加上Pathauto这样的模块，通常会生成与WordPress开箱即用时生成的URL结构完全没有重叠的结构。Drupal中的节点/content/our-services/web-design在WordPress上会变成/our-services/web-design，甚至根据你设置永久链接的方式可能是/web-design。这些是不同的URL。Google会把它们视为不同的页面。如果没有重定向，旧URL就死了。/content/our-services/web-design becomes/our-services/web-design or even/web-design on WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.
问题不仅仅是 URL。Drupal 的分类法系统映射到 WordPress 的分类和标签——但不完全匹配。Drupal 中的自定义内容类型变成 WordPress 中的自定义文章类型，如果你在迁移前没有建立这些 CPT，你的内容就会进入完全错误的地方。我曾见过一个 Drupal 驱动的新闻网站，800 个"文章"节点全部被导入为标准 WordPress 文章，覆盖了他们内部链接所依赖的自定义存档结构。
这是大多数开发者忽略的地方：你在迁移前在 WordPress 中做出的每一个结构决策都直接影响迁移后你需要设置的重定向。先把架构做对。重定向是补丁，不是计划。every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a plan.
---
第 1 步：迁移前审计——在迁移前了解你要迁移的内容
在动任何Drupal安装之前，必须完整爬取线上网站。我使用Screaming Frog设置为爬取最多500000个URL（付费版本）。导出所有内容：URL、状态码、标题标签、元描述、H1、规范标签、入站内部链接、字数。Screaming Frog set to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.
同时拉取你的 Google Search Console 数据。按过去 16 个月的点击次数筛选（不是 3 个月或 6-16 个月，因为你想捕捉季节性内容）。导出每个至少收到过一次点击的 URL。这些是你的保护 URL。如果失去这些 URL 的排名，客户会注意到。protected URLs. Lose rankings on any of these and the client will notice.
我特别要找的是：
- 删除Drupal网站上已经存在的重复内容（在迁移前修复，而不是之后） already existing on the Drupal site (fix it before migrating, not after)
- 字数少于 200 字且没有排名的内容页面——这些可以合并或删除，而不是迁移 under 200 words that rank for nothing -- these can be consolidated or deleted rather than migrated
- 非标准URL模式，比如/node/1234这样的URL，即使Pathauto处于活跃状态，Drupal有时也会暴露 like
/node/1234URLs that Drupal sometimes exposes even when Pathauto is active - 有排名的分类存档页面——/tags/、/category/、/topic/ 路径有实际的 Search Console 展示次数 that rank --
/tags/,/category/,/topic/paths that have actual Search Console impressions
最后这一条经常让人栽跟头。Drupal分类术语页面通常会为长尾查询排名。如果你不重建等效的WordPress分类存档并重定向旧路径，你就等于丢弃了被动流量。and redirect the old paths, you've just thrown away passive traffic.
---
第 2 步：URL 映射——没人想建的电子表格
乏味？是的。不可协商？也是的。
在Google Sheets中构建URL映射（如果你更喜欢Airtable也可以，我两者都用过）。A列是每个Drupal URL。B列是它将解析到的对应WordPress URL。C列是状态：精确匹配、需要重定向、合并或删除。exact match,redirect needed,consolidate, or delete.
对于一个 300 页的网站，这需要半天时间。对于一个 8,000 页的网站——Seahawk 在 2021 年为一个高等教育客户处理过——需要三个人花费大约四个工作日加上一个非常冗长的周五晚上。每次都是值得的。
我遵循的一些规则：
- 尽可能保留slug。如果Drupal有/blog/how-to-fix-crawl-errors，让WordPress使用相同的slug。大多数时候你可以做到。WordPress设置中的固定链接设置→固定链接允许你匹配Drupal使用的任何模式。If Drupal has
/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using. - 永远不要重定向到首页。懒惰的开发者才会这样做。这样做会损失链接权益，也会让用户感到困惑。每个旧网址都应该有具体的重定向目标。Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
- 注意分页 URL。Drupal 分页看起来像 ?page=1。WordPress 使用 /page/2/。映射这些或将其留为 404（通常没问题——分页页面很少保留有意义的链接权重，但先在 GSC 中确认）。Drupal pagination looks like
?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine -- paginated pages rarely hold meaningful link equity, but confirm in GSC first). - 分别处理查询字符串。类似 /search?keys=wordpress 这样的不需要重定向。/events?date=2023-06 可能需要，取决于这些页面是否有排名。Things like
/search?keys=wordpressdon't need redirects./events?date=2023-06might, depending on whether those pages rank.
---
第 3 步：内容迁移——从 Drupal 迁移到 WordPress 以及实际发生的情况
FG Drupal to WordPress 插件为大多数迁移承担了繁重的工作。它直接连接到你的 Drupal 数据库，提取节点、用户、分类法和媒体。对于 Drupal 7，效果非常好。对于 Drupal 9/10，你需要付费版本，上次我查的时候大约是 €99。与手动迁移相比，这笔钱花得很值。FG Drupal to WordPress plugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual migration.
该插件擅长处理的内容：
- 节点正文内容（如果你正确配置了媒体路径，包括嵌入的图像）
- 映射到 WordPress 分类和标签的分类术语
- 如果你购买了高级版本，还能处理基本的自定义字段
它不会处理的内容，你需要手动修复：
- Drupal Views——这些是自定义页面布局/查询。你需要在 WordPress 中使用 WPGridBuilder 等插件或自定义 WP_Query 循环来重建它们 -- these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
- Webforms——手动将这些映射到 Gravity Forms 或 WPForms；逻辑无法转移 -- map these to Gravity Forms or WPForms manually; the logic doesn't transfer
- 复杂字段组——Drupal 的 Field API 支持某些特别复杂的数据结构。你需要将这些导出为 CSV，然后通过 WP All Import 导入 -- Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
- 块内容区域——Drupal 的块系统与 WordPress 小工具/FSE 块完全不同。这是设计决策，不是迁移任务 -- Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task
FG Drupal to WordPress完成后我总是要做的一件事：运行行数统计。Drupal中有多少个节点？WordPress中现在有多少篇文章/CPT条目？它们应该匹配（除了你故意排除的内容）。在一个5000节点的网站上3%的差异是150个缺失的页面。去找到它们。
---
第4步：在不破坏服务器的情况下实施重定向
一旦 URL 映射建立好，内容在 WordPress 测试环境中上线，就该处理重定向了。两个工具可选：小网站（大约 1,000 个重定向以下）用 Redirection 插件，更大规模的 Apache 用 .htaccess 规则，或 Nginx 用 nginx.conf 块。Redirection plugin for smaller sites (under ~1,000 redirects) and.htaccess rules for anything larger on Apache, or nginx.conf blocks on Nginx.
为什么要区分？Redirection插件通过PHP处理重定向，这意味着每次重定向检查都会产生一次服务器请求。对于5000个重定向和每日50000次页面浏览量，这会产生真实的开销。服务器级重定向快数个数量级。
对于大型迁移，我会从 Google Sheets 导出 URL 映射，快速写一个脚本生成 RewriteRule 块，然后在上线前放入 .htaccess。花 20 分钟。省去上线后调试缓慢网站的数小时。RewriteRule blocks, and drop them into.htaccess before go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-launch.
有一点人们常想不到：重定向链。如果 Drupal 已经有重定向（很多成熟的 Drupal 网站都有，通过 Redirect 模块），你需要找到它们并合并链条。A → B → C 需要变成 A → C。Google 自己的文档很清楚地说明链条会减慢 PageRank 传递，即使不会完全阻止。redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentation is pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.
---
第 5 步：上线后——72 小时窗口
在星期二或星期三上线。绝不在星期五。我在 2018 年和一个客户的案例中吸取了教训——我们在星期五下午上线了一个 1,200 页的迁移，晚上 6 点发现了配置错误的固定链接结构。到周一时，Google 已经爬取并索引了大量损坏的 URL。
以下是我在前 72 小时监控的内容：
- GSC 覆盖率报告——注意 404 的激增。有些是预期内的（旧的 Drupal 系统路径）。如果在你的主要页面上出现激增，那就不正常了。 -- watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
- Screaming Frog 重新爬取——在上线后的早上爬取你的实时 WordPress 网站。将 URL 数量与迁移前的基准进行比较。 -- crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
- 重定向抽查——手动测试 GSC 中流量最高的 20 个 Drupal URL。将它们粘贴到浏览器中。它们是否导向了正确的位置？ -- manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
- 规范标签 -- 确认 WordPress 在每个页面上输出了正确的规范标签。Yoast 和 Rank Math 都会自动执行此操作，但还是要检查一下。 -- confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
- XML 网站地图提交 -- 立即在 GSC 中提交新的网站地图。不要等待 Google 自动发现它。 -- submit the new sitemap in GSC immediately. Don't wait for Google to find it.
我做的一件大多数人会跳过的事情：迁移后也要在 GSC 中提交旧的 Drupal XML 网站地图，指向旧域名或子域名（如果你暂时保留了它）。这能准确告诉 Google 哪些旧 URL 需要抓取、跟踪重定向并更快更新索引。submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.
---
第 6 步：30 天 SEO 健康检查
迁移在上线后并未真正完成。索引需要时间更新。以下是我在 30 天标记时检查的内容：
- 排名位置变化 -- 使用 Ahrefs 或 Semrush 比较迁移前 30 天与迁移后 30 天的关键词排名。预计某些词的排名会有轻微波动（5-10 个位置）。主要关键词排名下降 30 个以上位置需要调查。 -- use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5-10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
- 反向链接目标 -- 如果你之前有外部反向链接指向特定的 Drupal URL，请检查那些 URL 是否正确重定向。Ahrefs 的 Lost Backlinks 报告可以显示这一点。破损的反向链接目标意味着你正在主动丧失链接权重。 -- if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
- 页面速度回退 -- WordPress 网站有时比优化良好的 Drupal 网站慢。对你 5 个最重要的页面运行 Lighthouse 审计，并与迁移前的基线进行比较。 -- WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
- 索引率 -- 有多少提交的 URL 被索引了？在 30 天时，你至少希望 80% 的主要内容页面被索引。任何低于 60% 的比率都表明存在可爬性问题（检查 robots.txt，确保你没有在 WordPress Settings → Reading 中意外阻止 Googlebot）。 -- how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).
Seahawk 去年有一个金融科技客户，在 30 天检查时发现 340 个产品页面意外被设置为 noindex，原因是迁移期间 Yoast 的一个批量操作配置错误。在 30 天时发现：下午就能修好。如果在 6 个月后才发现：可能是一个排名漏洞，你还在试图弥补。noindex by a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.
---
常见问题
Drupal 迁移到 WordPress 实际需要多长时间？
完全取决于网站规模和内容复杂性。一个 50 页的宣传网站：2-3 天（包括 QA）。一个拥有 5,000 页新闻存档和自定义内容类型的网站：6-10 周。SEO 工作 -- 审计、URL 映射、重定向实现、迁移后监控 -- 通常会在核心开发估计的基础上增加 30-40%。不要让任何人告诉你别的。
从 Drupal 迁移到 WordPress 后会失去排名吗？
短期波动是正常的，几乎是不可避免的。如果你正确完成了 URL 映射、重定向和规范标签，大多数排名会在 6-12 周内稳定下来。我见过遭受永久丧失排名的网站都有同一个问题：要么没有重定向，要么大量重定向指向首页。做好这些工作。排名会恢复。
应该迁移所有 Drupal 内容还是从零开始？
取决于内容对你的作用。拉取你的 GSC 数据。任何在 16 个月内零点击且没有反向链接的内容都是候选删除对象，而不是迁移对象。迁移低价值的薄弱内容会让你的 WordPress 网站臃肿，可能稀释爬虫预算。要无情一点。也就是说，永远不要删除拥有任何外部反向链接的 URL，即使该页面本身很糟糕 -- 将其重定向到相关的页面。
Drupal 迁移后应该使用什么 WordPress 主题？
老实说，如果你用的是结构良好的 HTML 并且控制好页面速度，主题选择对 SEO 的影响几乎没有。我默认用 GeneratePress，因为它的标签干净、开销最小；如果客户想要更多设计灵活性，就用 Kadence。避免那些页面构建器堆砌型的主题，它们在每次页面加载时输出 400KB 的未使用 CSS。GeneratePress for its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.
我需要开发者还是可以自己做？
对于一个拥有 50 页以下、内容简单且没有自定义文章类型的小网站？你可能可以用 FG Drupal to WordPress 和 Redirection 插件管理，按照上面的步骤操作。对于任何更大的网站，或任何具有 CPTs、复杂分类法或有意义的现有 SEO 足迹的网站 -- 聘请开发人员。修复失败迁移的成本总是高于首次正确执行的成本。
---
迁移本身可能只占工作的40%。另外60%是你在迁移周围建立的SEO基础设施——URL映射、重定向、监控，以及要有耐心在30天内观察数据才能宣布成功。我见过精心构建的WordPress网站因为重定向工作草率而在搜索中表现糟糕，也见过简陋、几乎没有主题的WordPress安装因为URL映射做得严谨而保持了所有排名。
把无聊的事情做对。其余的往往会自然而然地跟上。