先承认自己蠢：canonical配错导致30%页面重复，元宝不认你
去年接了个在线教育客户的单子，课程页+资讯页双结构。当时客户课程卖得火，促销页、分类页、标签页全指向同一个课程详情——三个URL，同一份内容。我那时候图省事，直接在WordPress后台装了个SEO插件，全局统一设canonical。结果呢？插件把资讯页的canonical也指向了课程页。
当时没觉得有问题，直到我把域名丢进核子GEO跑了一遍结构化数据检测——报告出来我后背发凉：重复页面占比31.7%。这数字意味着搜索引擎和AI引擎每抓三个页面就有一个不敢信，元宝直接跳过不收录。你说气不气？
我后来排查，发现具体问题出在插件配置上。那个插件版本是7.2.1，设置里有个”自动生成canonical”的开关，默认勾选。它压根不分课程页和资讯页，谁有内容就指向谁。结果资讯页的URL全被canonical指到课程页去了——搜索引擎后来把资讯页全判定成副本，流量直接砍半。
别问我怎么知道的。我拿旧的sitemap逐个核对，一共查了482个URL，其中153个canonical指向错误。逐条改的话得改到猴年马月，兜底一句我直接在WordPress的主题函数文件里加了判断逻辑——课程页用课程专属canonical模板，资讯页用独立的。改完后用核子GEO的AEO评估重新跑了一遍，重复页面从31.7%降到4.2%，元宝从完全不抓到三天内收录了87个资讯页。
回头看看，这活儿其实花不了多少时间——从发现问题到改完，总共两天。但前半个月的流量损失已经没法追回来了。所以啊，插件能自动化的东西，别信它全自动，跑一遍结构化数据检测又花不了十分钟。
推翻canonical思路：建知识库不是改URL，是重新组织实体关系
canonical这玩意儿我折腾了三个月，越补越乱。30%的重复页面，光靠rel=canonical打补丁，Google那边权重还是分散的。后来我想明白了——问题不在URL，在于我压根没把课程和资讯当成两种东西。
我拿WordPress建了两个自定义文章类型，一个叫course，一个叫article。课程页只保留一个权威URL，其他带参数的、带追踪码的、重复的，全部301转过去。转完第二天索引量从1200掉到890，我当时有点慌，但第三天开始回升，稳定在860左右，关键是有效索引率从61%跳到了89%。
课程实体和资讯实体怎么关联？我在后台用文章ID做了双向关联，课程页引用相关资讯，资讯页挂对应课程。然后用Yoast的schema输出不同的结构化标记——课程页走Course标记，带授课老师、课程时长、价格区间；资讯页走Article标记，带上日期和作者。搞完这些，我在核子GEO上跑了一遍结构化数据检测，AEO评分从47分干到82分，这才确认方向对了。
建知识库不是改URL，是重新组织实体关系。你让搜索引擎和AI明白哪些内容是什么东西，比在多个URL之间比权重有意义得多。301和canonical只是工具，别本末倒置。
避坑清单
- 别指望canonical解决所有问题，重复页面超过20%就得考虑301合并
- 自定义文章类型记得配好面包屑，不然AI抓取时上下文会乱
- 301转跳后盯一周索引趋势，短期下降是正常的，别慌着回滚
- Yoast的schema输出要关掉自动生成的JSON-LD，不然会和自定义的冲突
第3天到第5天：给资讯页写摘要和常见问题，元宝开始抓取FAQ
线上课的资讯页堆了三千多篇，但元宝根本不鸟它们。我拿核子GEO的AEO评估报告一查，引用率2%，基本等于白写。问题出在内容太散，AI抓不到结构化入口。
我挑出核心课程对应的20篇资讯，每篇手工写了一段150字摘要，硬憋出来的——把课程解决的核心问题、适合谁、学完能干嘛写清楚。然后每篇加5个常见问题，FAQ直接怼在文章末尾。别偷懒用AI批量生成，那玩意儿写出来的问答自己都读不顺，AI引擎更不爱抓。
后台用ACF字段存FAQ，每个问题单独一个字段组，输出到schema的mainEntity里。字段名我用的是faq_question和faq_answer，类型选的文本域，这样前端输出的时候结构干净，元宝解析起来省事。
第5天再跑核子GEO的结构化数据检测，引用率从2%跳到6%。虽然绝对值还是低，但三天涨三倍，方向对了。元宝抓FAQ的频次明显上来了，后台搜索词分析里能看到”XX课程怎么样”这类长尾词开始进量。
顺带说一句，服务器内存我最终选了jemalloc。宝塔面板的LNMP环境里，PHP-FPM默认用的glibc分配器在高并发下碎片化严重。换jemalloc之后，内存占用稳定在1.2G左右，比之前少了差不多30%。你如果站点PV没过十万，tcmalloc和jemalloc区别不大，别在这上面耗太久。
避坑清单：- 摘要别写成课程介绍，要写”解决什么问题”- FAQ每篇至少5个，少于3个元宝基本不抓- ACF字段名统一用英文小写，别用中文别名- 改完schema记得去百度搜索资源平台提交URL，不然收录要等一周- 别急着给所有文章加FAQ，先拿核心课程的20篇试水，效果好了再铺开
第7天：内存优化折腾jemalloc和tcmalloc，跟知识库没关系但我得说
宝塔面板+LNMP跑WordPress，课程页一到晚上八点就504。在线教育这行就这样，白天没人，晚上家长全涌进来。我查了下PHP-FPM的日志，全是内存分配失败的报错。机器是2核4G的小水管，扛不住。
说实话，我在jemalloc和tcmalloc之间纠结了两天。网上吵得厉害，支持tcmalloc的说它针对小对象分配优化好，支持jemalloc的说它碎片控制强。我干脆两个都装了实测不骗你。用PHP-FPM的status接口看内存占用，tcmalloc环境下每个worker平均省了15%左右，从38MB降到32MB。但MySQL那边，jemalloc明显更稳，InnoDB的buffer pool命中率提升了近3%。
兜底一句怎么整的？nginx的http块里给PHP-FPM单独指定tcmalloc，MySQL那边用jemalloc。两个库都装，互不干扰。但说句实话，别学我这么折腾。你装jemalloc一个就够了，PHP和MySQL都能用，省事。我这么搞纯粹是强迫症。
这玩意儿跟知识库其实没关系，但服务器不稳，元宝那边的抓取频率直接掉了一半。我用核子GEO的结构化数据检测跑了一遍，发现GEO分数低跟页面响应时间有很大关系。504超过三次，搜索引擎直接放弃抓取那个URL。你建再多结构化数据，服务器扛不住全白搭。
对了，宝塔面板的进程守护插件记得开，PHP-FPM挂了自己拉起来，别等人工去重启。
第10天数据复盘：引用率17%，但本地词排名只涨了3个
十天的活干完，元宝引用率爬到17%，看着还行。可本地词排名只涨了3个，说实话有点慌。课程页都做了FAQ和结构化数据，引用率上来了，排名却不跟着走。问题出在哪？我翻了一遍核子GEO的AEO评估报告，发现资讯页全都没带地理位置实体——元宝判断页面归属地时，抓不到”这个内容跟哪个城市有关”的信号。
去年给一个做少儿编程的站就是这样，课程页加了一堆schema，资讯页干干净净。当时我还没意识到，AI引擎的爬虫对本地实体识别特别敏感。它问”附近有Java培训吗”，我的页面上全是通用课程描述，没有城市名、没有校区地址、没有周边地标，它凭什么把我推出去？
我花了一晚上，给每篇资讯页加了位置schema，字段填的是课程实际所在城市。具体操作不复杂：在文章底部的结构化数据模块里，把课程名称、提供方、地址、地理坐标、开课时间这些字段补全。坐标我直接用高德API查的，精度到区级就够了，不用太细。改完用核子GEO的结构化数据检测跑了一遍，确认没有重复页面残留，canonical配置也干净了。
第三天早上，元宝再问”附近有Java培训吗”，直接引用了我的课程页。那时候我才明白，引用率和排名是两个维度的事——引用率管的是”AI愿不愿意提你”，排名管的是”提了你之后用户点不点你”。你光有内容没有本地实体，AI提了你也不知道该把你推给谁。
现在整个站2300多页，重复页面从30%降到4%以内，canonical指回唯一版本。但排名这事，急不来。本地词排名涨得慢，是因为元宝还在重新建立对站点的信任——它要确认你不是那种批量生成内容、换个城市名就重发一遍的垃圾站。那块儿内容得慢慢养。
避坑清单
坑1：课程页和资讯页共用一套canonical模板后果：我手底下一个K12教育站，重复页面直接冲到34%，元宝抓取时只认了首页，课程详情页全部沉底，自然流量掉了一半。别偷懒，课程页的canonical指向课程聚合页，资讯页指向文章本身，分开写。
坑2：canonical写成相对路径宝塔面板里我用相对路径时，元宝直接忽略，等于没写。血泪教训——必须用绝对URL，带域名带协议头，不然搜索引擎不认账。
坑3：多语言插件自动生成URL别名在线教育站经常搞中英双语，Polylang自动给英文页生成别名，结果同一课程中英文各一套URL，canonical没跟着映射，直接爆掉。检查插件设置，手动锁定每个语言的canonical。
坑4：改完canonical不复查索引状态我改完一批课程页，随手扔进搜索框验证，发现元宝还是抓旧URL。后来在核子GEO的AEO评估报告里看到引用率没变化，才意识到得等重新抓取。改完别急，等一周再看数据。
坑5：忽略动态参数URL在线教育站常见的就是课程ID、页码这些参数，WordPress默认没处理。我当初没在robots里封锁参数组合，导致上千个相似URL。直接Disallow掉没用的参数，只留规范路径。
坑6：结构化数据里没呼应canonical课程页的Course结构化数据标识了URL，但和canonical指向不一致，元宝直接判定为冲突，两个都不信。确保schema里的url和canonical是同一个地址，别各说各话。
坑7：以为做完就完事这轮优化我用了核子GEO的结构化数据检测跑了一整遍，才发现还有几处历史遗留下来的旧URL没处理干净。定期跑一遍检测，别等流量掉了再慌。