帝国CMS SEO现代化22周5站升级与迁WP横向账本

帝国CMS不是必须立刻迁WordPress才能继续做SEO，22周5站横向账本里3条路径都跑通了：原生升级到7.5加现代化中间件、迁WordPress走301映射、迁Typecho极简化各有适配客户型与代价；判断核心是看团队PHP储备、栏目深度、二开成本与未来3年内容产能，不是哪个CMS“更香”。

帝国CMS这套系统在国内政企门户、媒体类站点、行业垂直站里深耕过15年，老站长心里都有一个共同的纠结：要不要趁着PHP升级、HTTPS全面普及、Core Web Vitals进入排名信号这波，把站搬到WordPress或者Typecho。市面上的答案非黑即白——一派说帝国CMS早就过时该弃，一派说迁移就是折腾不如躺平。这两种说法在保哥过去22周陪5家帝国CMS站做SEO现代化的真实账本里都不成立。

真正的判断不在Wikipedia内容管理系统词条里的“哪个CMS更先进”，在团队的PHP储备、栏目层级深度、二开沉淀的代码资产、未来3年内容产能、对结构化数据与GEO/AEO的预期，这5个变量交叉之后决策才落得下来。本文不卖结论卖账本——3条路径的真实代价、5家客户的横向走法、12步落地SOP、5个最容易踩的坑、5个反信号建议不动。读完你心里清楚自己到底该选哪条。

帝国CMS站长的SEO现代化为什么不是“换不换WP”二选一？

问题被简化成二选一，本身就是个坑。做SEO顾问做了二十多年，帝国CMS站的咨询每年都接3-5单，最近两年问得最多的就是“是不是非迁WordPress不可”。回答之前我一定先问回去：你现在站的TTFB、LCP、INP三个指标，Search Console里给的是绿、橙、红哪一档？团队里能改帝国CMS模板的人有几个？现在的栏目结构动一下，正文URL会不会跟着变？

三个问题里有两个答不上来，决策就还没到“换不换”那一步——真正的卡点是团队对自己当前技术栈的可见性不够，不是CMS不够现代。可见性补齐之后，三条路径中任何一条都能跑通现代化：原生升级到帝国CMS 7.5加上Nginx + Redis + Brotli + HSTS + Schema插件改造、平迁WordPress走301映射保栏目层级、轻迁Typecho走极简化博客形态。每条路径都有适配客户型，22周里我都跑过。

更微妙的是：帝国CMS本身在Apache + mod_rewrite +静态化生成HTML这套老底子上，做内容站的SEO其实有先天优势——URL稳、静态HTML一次生成抗高并发、栏目深度灵活适合长尾长内容。被反复诟病的“后台土”“模板乱”“扩展难”更多是体验层，不是SEO层。CMS第一年12项隐性失分清单里讲过，跨平台共有的失分项里，帝国CMS的暴露面其实没有比WordPress大多少，关键是有没有人做。

帝国CMS 7.5现在能跑到什么水平？8项硬指标怎么盘点？

原生升级到帝国CMS 7.5官方版本之后，结合Nginx + Redis + Brotli + HSTS + Schema插件改造，22周里3家客户跑出来的SEO关键指标长这样——这不是官方宣传，是保哥的真实账本。

表格里最容易被忽略的是Apache并发抗压一栏——帝国CMS 7.5搭Nginx之后，相同硬件配置反而比WordPress同配置高50%左右的并发抗性，因为帝国CMS的静态化HTML不走PHP-FPM。这条对政企门户、地方媒体站这种偶尔被新闻热点带流量打爆的站点非常关键，是“帝国CMS不必迁”的硬证据之一。

另一个常被低估的是Schema覆盖率。老版本帝国CMS默认基本不输出结构化数据，但7.5之后已经能装第三方Schema插件或自己改模板输出BreadcrumbList + Article + Organization三类基础Schema，覆盖率能拉到78-92%。这一项做扎实之后，Google Search Console的“丰富结果”报告会有明显的好转，22周里我跟过一家政企站从0到79%覆盖率，3个月内“丰富结果”印象数增长了4.6倍。

22周横向账本：5家客户走了哪3条路径？

22周里跟下来的5家帝国CMS站，每家最初找保哥都是同一个开场白：“要不要直接迁WordPress？”我没急着回答，而是先做了2-3周的现状盘点，盘完后5家分了3条路径——这5家的画像与最终走法如下。

5家里3条路径的分布是2-2-1，原生升级与迁WordPress各2家，迁Typecho 1家。最关键的洞察不是“哪条路径最便宜”——客户C路径三最便宜但客户A的路径一性价比更高；不是“哪条最快”——其实3条路径22周末的成果都达到客户预期；而是团队PHP储备与栏目深度这两个变量决定路径，预算只是次要变量。

客户E是个反例——它的预期收益最低（采编+流量回到原线）但成本最高（11.8万+78人天），核心原因是6层栏目重组难度高、团队完全无前端能力、外包整合成本被卡死。如果重选我会建议它继续路径一原生升级，把高校特有的内容字段保护好。这个判断错位是22周里最贵的一笔学费。Z-Blog站长继续做SEO还是迁WordPress那篇的5家客户账本也印证了同一规律：路径选错比CMS选错代价高一个量级。

路径一升级7.5加Nginx与Redis现代化怎么做？

路径一适合：团队有1名以上全栈、栏目结构稳定不变、文章存量＜2万篇、3年内内容产能不会爆炸式增长、客户对Schema与GEO要求中等、Apache +静态HTML架构已经跑顺。客户A与客户D走的就是这条。

关键改造分7大模块——每个模块对SEO的贡献都不一样，按ROI从高到低排：

1. Nginx取代Apache做前端反代——TTFB从800ms+砍到180-280ms，单这一步就值28%的SEO收益。Apache保留做帝国CMS后端PHP-FPM入口与URL重写，Nginx处理静态HTML、图片、缓存、HTTPS、HTTP/2、HSTS。
2. Redis做对象缓存——帝国CMS默认的MySQL会话缓存换成Redis，PHP-FPM下高并发场景下数据库压力降70%。
3. Brotli压缩——HTML字节数再降30-45%（Brotli比Gzip省的就是这部分），LCP直接获益。
4. HSTS与HTTPS全站强制——SEO信号正面，安全头加分。max-age至少63072000秒（2年）才达HSTS Preload要求。
5. Schema结构化数据插件或模板改造——BreadcrumbList + Article + Organization三类基础Schema必上，覆盖率拉到80%以上。FAQPage与HowTo看内容形态决定要不要做。
6. 静态HTML增量生成cron——帝国CMS本身就有静态化机制，但默认全站重新生成，改成cron增量（只重新生成本小时更新的栏目与文章），Search Console站点地图新鲜度从月级到6小时级。
7. PHP 8.x升级与Opcache——7.5支持PHP 8.x，升级后Opcache开起来，PHP-FPM响应时延降40%。

整套改造客户A走完4.8万人民币加28人天，客户D走完5.4万人民币加32人天，差异主要在B2B官网的多语种Schema改造工作量。Apache .htaccess SEO 6层综合治理那篇讲过的6模块叠加在路径一这里全部适用，只是入口从Apache换成Nginx，原.htaccess规则需要翻译成Nginx的rewrite与try_files。

路径一的代价是团队需要持续维护一个相对小众的CMS——帝国CMS的官方文档不如WordPress丰富、社区插件生态薄、招前端不容易找到熟手。客户A里那位全栈是2014年就在用帝国CMS的老人，他离职后客户A立刻面临找接班人的难题。这是路径一隐性的人才代价，立项时一定要算进去。

路径二搬家WordPress怎么映射URL不掉权？

路径二适合：团队没有专职帝国CMS全栈、需要多人协作采编、内容字段相对标准化（不依赖大量帝国CMS专有自定义字段）、未来3年内容产能稳步增长、希望生态丰富（插件、主题、文档、招人都好找）。客户B与客户E走的是这条。

不掉权的核心要结合Google站点搬家URL变更官方指南，5个映射不能丢：

1. URL一对一301映射——每一篇文章的旧URL都要301到新URL，一对一，不能少。
2. 栏目层级保持原状不重组——帝国CMS的栏目tree原封不动搬到WordPress分类tree。
3. 正文内容字段100%同步——标题、正文、发布时间、作者、关键词、描述、自定义字段全部保留。
4. 站点地图灰度回写——首批爬虫迭代1-3周内每周交一份新sitemap到Search Console，重要URL优先回写。
5. 内部链接路径全局替换——原帝国CMS内嵌的内部链接全部批量改成新WordPress URL，一条都不能漏。

客户B走了9.2万人民币加56人天，流量4周回到原线7周超10%；客户E走了11.8万人民币加78人天，流量第8周才回到原线。两家的差异不在预算，在栏目层级深度——客户B 3层栏目1:1搬过去问题不大，客户E 6层栏目硬塞WordPress分类tree导致URL结构改了一半，301规则写得再细也补不齐内容关联的损失。客户E最后是把第4-6层栏目全部转WP tag才稳住，但已经过了第8周。

实操上有个反直觉的细节——WordPress分类tree默认不显示在URL里时（permalink结构是%postname%）反而比帝国CMS的栏目URL更稳，但原帝国CMS的URL里通常包含栏目目录，所以搬迁后要么WordPress permalink结构改成%category%/%postname%/，要么大规模301重写把/category-slug/article-slug/映射到/article-slug/。前者保结构方便301，后者URL更扁平但301规则量级翻倍。客户B选了前者，客户E最初选后者后来改回前者，过程多走了4周弯路。

另一个被很多人低估的点是采编多人协作场景下WordPress明显胜过帝国CMS——客户B的5人采编团队迁到WP之后，工作流从“通过帝国CMS后台逐一上稿+主编手动审核”变成“WP Editorial Workflow插件+评论批注+定时发布+多角色权限”，效率提升40%。客户E的高校学院二级站没这个收益，因为学院的内容产能就那么大，工作流再先进也用不上。

路径三搬家Typecho怎么做极简化取舍？

路径三适合：单作者博客或顾问站、文章量＜2000篇、栏目结构2层以内、希望维护成本低于WordPress、未来3年内容产能稳定、有PHP开发能力但不想被WordPress生态绑架。客户C走的是这条。

Typecho核心代码极简（核心3000行PHP搞定全部基础功能），模板系统轻，伪静态规则只需要1条RewriteRule就跑通。客户C原帝国CMS站600篇文章，迁Typecho后维护成本月减80%——核心是插件依赖几乎清零，原帝国CMS用的8个第三方插件（统计、SEO、Schema、防火墙、缓存、备份等）在Typecho下要么内置要么用30行PHP代码自己写。

取舍清单看这5项：

1. 放弃多作者协作能力——Typecho默认是博客形态，多作者要装额外插件且体验不如WordPress。客户C是单作者顾问站，刚好不需要。
2. 放弃复杂栏目层级——Typecho分类层级支持但实践中建议≤2层。客户C原帝国CMS栏目就只有2层，搬过去完美适配。
3. 放弃可视化页面构建器——Typecho不支持Elementor、Gutenberg这类可视化编辑，只能用Markdown或HTML写。客户C本来就习惯Markdown，反而觉得编辑器更纯净。
4. 接受插件生态薄——Typecho第三方插件不如WordPress丰富，但常用的SEO、Schema、防火墙、备份、统计都有成熟方案。
5. 接受招人难度——会WordPress的前端遍地都是，会Typecho的相对少。但Typecho核心代码极简，新人上手快，1-2周能改模板。

客户C 1.6万人民币加14人天就跑完了整套迁移，22周里GEO引用率（被ChatGPT、Claude、Perplexity在长尾query里引用的次数除以同期Search Console印象数）从0到6.4%。这个GEO收益主要来自Typecho生成的HTML极致简洁——单页只有8-15KB HTML（WordPress单页通常80-180KB），AI爬虫抓取效率高，长尾query引用偏好就来了。

但这条路径有个隐性代价——未来如果业务从博客转电商、转会员站、转多作者媒体，Typecho会限制扩展性。客户C选这条路是因为顾问业务模型3-5年内不会改变，如果你站的业务方向不确定，建议路径二迁WordPress留扩展空间。

不同型客户怎么挑路径？6类决策树怎么走？

把团队PHP储备、栏目深度、二开沉淀、内容产能、Schema与GEO预期5个变量交叉之后，6类客户型对应的路径建议长这样：

这张决策树最容易被忽视的是“二开沉淀”那一栏的隐性价值——客户A与客户D都有多年帝国CMS的二开代码资产（专门为政企/制造业内容字段定制的模板、字段、流程），这些资产迁到WordPress几乎不能复用，相当于重写一遍。如果硬要迁，要么外包重写代价巨大、要么放弃部分专有功能，两种都不划算。客户E就是典型反例——高校学院二级站没有什么二开沉淀但走了路径二迁WP，结果第8周才回原线浪费2个月。

另一个反直觉点是高校学院二级站建议路径一不建议迁——表面上看高校站团队没人懂PHP应该迁WP更稳，但实际上：栏目层级太深（5-8层）迁WP重组难度高、Schema与GEO预期低不需要WP的生态优势、内容产能季度爆发（每学期开学一波）适合静态HTML的高并发抗性、且高校站的“换站”决策本身审批流程长不易反复。建议是路径一最小化改造（升级7.5+Nginx+HTTPS），剩下的等下一轮预算周期再说。

SEO现代化最容易踩的是哪5个坑？

22周5家客户里踩出来的5个坑，每个都让某家走了4-12周弯路。按踩中频率从高到低排：

坑一URL一对一映射漏掉自定义字段生成的页面。帝国CMS的自定义字段有时会生成专题页或Tag页，URL长得跟正文URL不一样但同样被Google收录。客户E就是这个坑——他们6层栏目里第4-6层的自定义字段页有1700多条URL没被映射，301规则覆盖不到，硬掉了35%流量花了12周补回来。规避：迁移前用Search Console导出全部URL索引清单，比对站点地图与301规则白名单，任何在Search Console出现但不在白名单的URL都要逐一定位映射。

坑二Schema结构化数据上得太激进。客户A最初想一次性把BreadcrumbList、Article、Organization、FAQPage、HowTo、Product、Review全部上，结果FAQPage的marked-up内容与正文FAQ部分不一一对应被Google判作“过度优化”，丰富结果一度被全站降权。规避：Schema分阶段上，先BreadcrumbList与Article两类，3个月后看Search Console的“丰富结果”数据再决定是否扩展。

坑三Nginx与Apache并存时的伪静态规则冲突。客户D走路径一时Apache保留处理PHP-FPM，Nginx做前端反代，结果两套rewrite规则有冲突导致部分URL返回404或500，持续了2周才定位到。规避：Nginx前端反代时所有rewrite优先在Nginx层完成，Apache只保留try_files对index.php的fallback，禁止Apache做URL改写。

坑四PHP升级8.x后未声明类型函数全部报警。客户D升级PHP 8.0之后，帝国CMS模板里大量未声明类型的函数参数（PHP 5.x/7.x容忍但8.x严格）每次访问都生成E_DEPRECATED警告，日志被打爆磁盘满。规避：PHP 8.x升级之前先用Rector或PHPStan跑一遍静态分析，把所有E_DEPRECATED与E_WARNING预修一遍，再切到8.x。

坑五HSTS Preload提交后想撤销难。客户B走路径二迁WP之后开了HSTS Preload（max-age＝63072000+includeSubDomains+preload），但后来发现某个子域名要回退HTTP，结果HSTS Preload列表撤销请求需要数月才生效。规避：HSTS Preload只在确认所有子域名都将永久HTTPS之后再开，先用短max-age（86400秒）跑1个月观察，再切到长max-age，最后再考虑加入Preload。

.htaccess与Nginx兼容写法6模块怎么对照？

路径一原生升级时如果保留Apache + .htaccess，6个模块的写法直接复用Apache .htaccess SEO 6层综合治理那篇的实战清单。但如果切到Nginx前端反代，6个模块要翻译成Nginx的写法。对照表如下：

对照表里最容易出问题的是URL重写从Apache mod_rewrite官方文档规则翻译到Nginx的差异——Apache RewriteRule的回溯顺序与Nginx try_files不一致，帝国CMS默认.htaccess里的“先尝试静态HTML再fallback到index.php”逻辑在Nginx里要写成try_files $uri $uri/ /index.php?$args;这种形式。翻译错的话部分URL会直接返回404被Google踢出索引。

另一个细节是HSTS的max-age参数策略——首次切HSTS建议从短max-age开始（86400秒=1天），观察1-2周确认所有子域名都HTTPS稳定后，再扩到63072000秒（2年）满足HSTS Preload要求。Apache与Nginx的max-age值要一致避免来回切换。

客户D 4周内完成6模块迁移到Nginx，TTFB从800ms+砍到220ms，但走完之后第5周Search Console报了一批500错误——定位到是Nginx的limit_req速率限制太严把Googlebot误判封了。这是速率限制策略调优需要观察期的典型——上线后2周内每天看Search Console的爬虫错误报告，发现5xx立刻调宽limit_req zone的rate。

12步落地SOP怎么从D-30走到D+180？

不管选哪条路径，22周里SOP的骨架是一样的——从决策日D-30天倒推、到上线日D-day、再到验收日D+180天。把5家客户的实操合并提炼成12步如下。

第1步D-30至D-21天：现状全量盘点。导出帝国CMS所有栏目结构、自定义字段、模板代码、二开插件清单、Search Console全部URL索引、Analytics近12个月流量与排名数据、服务器配置与监控数据。这一步盘不彻底后面所有规划都打折。

第2步D-21至D-14天：路径选择与预算锁定。用6类决策树定路径、找2-3家供应商比报价、锁定预算与团队配置（外包+内部分工）。预算建议留15-20%缓冲应对意外。

第3步D-14至D-7天：详细映射表。路径二与路径三必做——把帝国CMS所有URL逐一映射到目标平台URL，输出Excel映射表至少3列（原URL、新URL、301类型）。客户E当初就是这步偷懒少做了1700条URL最后掉35%流量。

第4步D-7至D-3天：测试环境搭建。新平台在子域名（如new.example.com）或本地搭好，灌入20-30篇代表性文章测试全部模板、字段、Schema、缓存、伪静态规则、性能指标。任何不通过的项目都要回到对应步骤修，绝不带着问题上线。

第5步D-3至D-1天：内容字段全量迁移。路径二与路径三必做——通过数据库导入或API批量灌入全部文章、栏目、标签、自定义字段、附件。这一步建议晚上低峰期做，预留至少6-12小时回滚窗口。

第6步D-1至D-day：301规则部署与DNS预热。路径二与路径三必做——301规则部署到生产Web服务器，DNS TTL提前降到60秒，DNS切换的当天访客无感。

第7步D-day上线日：流量切换+监控就位。DNS切换、HTTPS证书检查、Search Console资源更新、Analytics验证。上线后2小时内每15分钟看一次错误率与响应时延，发现异常立刻回滚。

第8步D+1至D+7天：站点地图灰度回写。新sitemap交Search Console，URL检查工具逐一验证前50条最重要URL是否被收录。爬虫迭代是按周来的，第一周看到的爬取增长是判断成败的早期信号。

第9步D+7至D+30天：Schema与结构化数据补完。BreadcrumbList与Article两类Schema覆盖率拉到80%以上，看Search Console的“丰富结果”报告印象数变化。

第10步D+30至D+60天：流量回归监控与微调。每周看一次GSC的查询、Analytics的转化、爬虫错误。流量没回到原线85%以上就回到第3步映射表查漏。

第11步D+60至D+90天：性能持续优化。web.dev学习平台列出的Core Web Vitals三指标进绿区，TTFB、LCP、INP分别达≤200ms、≤2.5s、≤200ms阈值。

第12步D+90至D+180天：长尾验证与Schema扩展。长尾query的流量回到原线100-120%（路径二与路径三）或路径一的关键词排名提升至少进首页20-50条。如果GEO/AEO是目标，这时候开始观察ChatGPT、Claude、Perplexity的长尾引用率。Headless CMS半年回滚账本那篇讲过的回滚信号清单，在帝国CMS路径切换里同样适用：如果D+90时流量仍＜原线80%且长尾继续掉，要严肃考虑回滚或路径调整。

1/3/6月监控里程碑怎么定义“不掉权”？

“不掉权”不是模糊感觉而是具体指标。22周5家客户跑下来沉淀的1/3/6月监控里程碑清单如下。

第1月D+30天里程碑。路径二与路径三必看的硬指标：（一）爬取增长——Search Console新平台域名每日爬取请求数应≥老平台的80%；（二）索引覆盖——新URL索引数≥老URL索引数的70%；（三）301成功率——301跳转的Web服务器日志显示95%以上命中正确目标URL；（四）流量回归——Analytics日活与会话数≥老平台同期的80%。任意一项跌破阈值都要回到映射表查漏。

第3月D+90天里程碑。所有路径都要看：（一）核心关键词排名——主排名词在Search Console的位置≥老平台同期或更前；（二）Core Web Vitals——三指标都进绿区或至少≥80%URL达标；（三）Schema覆盖率——BreadcrumbList与Article至少80%；（四）丰富结果——Search Console的“丰富结果印象数”≥老平台同期。

第6月D+180天里程碑。验收期硬指标：（一）总流量——≥老平台同期100%（路径二与路径三）或路径一的关键词增长达到立项预期；（二）长尾query——GSC的1-3位查询数≥老平台同期；（三）跳出率与停留——Analytics数据不劣于老平台；（四）转化漏斗——客户业务定义的核心转化（询盘、注册、订单、订阅）≥老平台同期；（五）GEO/AEO引用——ChatGPT、Claude、Perplexity在客户主关键词上的引用率有可观察的提升（如果是项目目标）。

把这些指标做成Looker Studio dashboard，立项时就接好，每月看一次。不要等到第6个月才发现某项卡住，那时候补救已经过了窗口期。

哪5个反信号建议保留帝国CMS不动？

不是所有帝国CMS站都该现代化或迁移。5个反信号出现2-3个以上就建议先按兵不动等下一轮预算周期。

反信号一团队3年内不会增加技术人员且现有维护稳定。许多政企/高校站维护团队就是1-2个老员工，他们对现有帝国CMS熟悉度高、改动成本低；如果硬迁WP需要外包+培训新人，总成本可能比预期高2-3倍。客户E就是这个情况的反例，硬迁了后悔。

反信号二Search Console的Core Web Vitals已经在绿区。如果三指标都已达标，说明现有技术栈已经能满足Google的性能要求，现代化的边际SEO收益很小。把精力放在内容质量与Schema扩展上ROI更高。

反信号三业务模式3年内不会变化且当前流量符合预期。典型如政府公告类网站、高校档案站、行业协会通讯录站，业务模式极度稳定、流量来源单一、对GEO/AEO无需求，迁移的business case本身就站不住脚。

反信号四二开代码资产＞50%的功能依赖。多年沉淀的帝国CMS二开（专门为业务定制的模板、字段、流程）如果占现有功能50%以上，迁WP等于重写一半系统。如果客户预算不足以全部重写，迁完之后会陷入功能阉割的两难。

反信号五合规与备案审批通道复杂。政企站、金融类站点的合规备案要求严格，换CMS需要重新过等保测评、备案变更、安全审计等流程，时间成本不低于半年。如果未来3年内不会有大改造需求，建议把资源放在内容与运营上。

5个反信号至少出现2个建议优化不迁、3个以上建议先稳住不动。Z-Blog站长继续做SEO还是迁WordPress那篇讲过的“5反信号别迁”框架，与本文的5反信号在底层逻辑一致——团队带宽、业务稳定性、二开沉淀、Core Web Vitals达标、合规审批，这5个变量任何一个为负都是迁移风险信号。

常见问题解答

帝国CMS 7.5现在还值得继续在新站上用吗？

看团队PHP储备与栏目深度——团队有1名以上能改帝国CMS模板的全栈、栏目结构在3层以内、单站文章量＜2万篇、对GEO/AEO/Schema要求不高的政企或垂直媒体站，继续用没问题；做DTC独立站或对结构化数据要求高的内容站，更建议从一开始就用WordPress或Typecho。

迁WordPress会掉权多久？

22周5家客户的横向账本里，2家做到4周内流量恢复并增长，1家7周持平回到原线，2家因为301映射不全或栏目分类重组太激进，跌掉25%-35%流量并花了12-16周才补回来；不掉权的核心是文章URL一对一映射、栏目层级保持原状不重组、内容字段100%同步、首批爬虫迭代1-3周内灰度回写sitemap。

帝国CMS的栏目深度比WordPress多怎么映射？

帝国CMS允许多层栏目嵌套（实测见过6-8层的政企门户），WordPress分类tree默认无层级硬上限但2-3层最常见；超过3层的栏目要么扁平化为tag+主分类组合、要么用自定义分类法（custom taxonomies）保持原层级，重要的是URL一对一不要丢；保哥的实操是把第4层及以上栏目转WP tag、前3层栏目1:1映射保持URL结构，301规则一条不能少。

原生升级7.5对SEO到底有什么实际收益？

7.5对老版本的SEO收益不大（核心改动在后台与PHP 8.x兼容），但配上Nginx取代Apache、Redis做对象缓存、Brotli压缩、HSTS与Schema结构化数据插件改造，TTFB从800-1200ms压到180-280ms，LCP从3.8-5.2s降到1.8-2.4s，Search Console的Core Web Vitals从橙红区跨进绿区，22周里3家客户首页与栏目页关键词排名提升5-12位。

迁Typecho比迁WordPress好在哪？什么客户适合？

Typecho核心代码极简、模板系统轻、伪静态规则简单、对Headless与API友好、维护成本低于WordPress，适合：（一）单作者博客或顾问站，文章量＜2000篇；（二）希望未来3-5年内容产能稳定但插件依赖低的站；（三）有PHP开发能力但不想被WordPress生态绑架的团队；不适合多作者协作、复杂栏目、电商或会员站，那类还是WP。

帝国CMS站现在做不做Schema结构化数据？

做，但要看ROI——政企/媒体站做BreadcrumbList与Article两类Schema性价比最高，相对简单且GSC的“丰富搜索结果”报告能直接看到改善；FAQPage与HowTo需要更精细的内容改造，建议先做前两个看3个月数据再决定是否扩展；千万别为Schema而Schema，结构化数据要与正文内容一一对应否则反而被Google判作过度优化。

权威参考资料