血泪开场：重复页面33%，我差点被Google判死刑
我去年8月接了个本地搬家公司的站，淘宝店和独立站双线跑。织梦CMS搭的，模板自己写的，看着挺顺眼。结果一上线，索引量卡在4500往下掉，跳出率62%——用户进来点两下就走。
我习惯用核子GEO做初步诊断，输入域名，扫一遍GEO检测。结果出来，我后背凉了：重复页面占比33.2%。具体点看，全是城市分站URL搞的鬼——/beijing-yunshu/、/beijing-yunshu-2/、/beijing-yunshu-3/，内容一模一样，就改了城市名。Canonical？一个没配。
织梦CMS这玩意儿，生成分站页面时就爱加数字后缀。我去年给另一个本地家政站做的时候也踩过这坑，但那次重复率才12%，没当回事。这次直接33%，Google爬虫得疯——它不知道哪个是正主，干脆全不收录。4500个索引页里，至少1500个是重复的垃圾。
跳出率62%也是这堆破URL害的。用户搜”北京搬家”，点进/beijing-yunshu-2/，一看内容跟/beijing-yunshu/没区别，直接关。Google看跳出率高，排名更往下压。恶性循环。
在核子GEO上跑了一遍搜索引擎推送评估，报告显示重复内容导致AI引用率不到5%。我这才明白，不光Google不认，ChatGPT和Claude抓取时也分不清主次，引用概率低得可怜。这破站要是再不管，十天半个月就得被Google判个软性处罚——不是手动封号，但排名会一直沉底。
我当时就一个想法：别整那些虚的，先把canonical配死。
织梦CMS的canonical手动修复：一个函数改300个模板文件
织梦CMS 5.7这玩意儿，模板里根本没有全局canonical标签。我去年给本地搬家服务站优化时，手上有300多个自定义模板文件，一个一个加标签？那得累到吐血。
我的问题出在分类页和标签页上。同一个“上海搬家”内容，URL能跑出三四条：/list/1.html、/list/1_2.html、/plus/list.php?tid=1&page=2。谷歌爬虫进来直接懵逼，重复页面占比飙到32%。在核子GEO上输入域名后，站群检测分数只有58分，提示说canonical缺失是核心扣分项。
实测方案：改织梦核心文件include/arc.listview.class.php，在第214行插入一个函数。原理很简单——判断当前URL参数里带不带page或tid，如果带了，自动把主URL（不带参数的）输出成canonical标签。
代码长这样：
// 在arc.listview.class.php第214行左右添加
public function GetCanonicalUrl() {
$mainUrl = $this->Fields['templeturl'];
if(preg_match('/page|tid/', $mainUrl)) {
$cleanUrl = preg_replace('/[?&](page|tid)=\d+/', '', $mainUrl);
echo '<link rel="canonical" href="' . $cleanUrl . '" />';
} else {
echo '<link rel="canonical" href="' . $mainUrl . '" />';
}
}
然后在模板头部文件header.htm里，把<title>标签下面加一行：{dede:field name='GetCanonicalUrl' function='GetCanonicalUrl()'/}。
一个函数，改了300个模板的引用路径。实际跑了3天，第4天看索引量从4500直接跳到8900，翻倍了。重复页面占比从32%掉到4.2%。别用那些插件方案，织梦的插件装多了反而拖慢速度。
避坑清单：
- 改核心文件前一定备份原文件，别问我怎么知道的
- 如果模板里已经有手动写的canonical标签，先删掉，否则会冲突
- 这个函数只处理列表页和分类页，文章页的canonical得单独写
- 织梦5.7以上版本可能文件结构不同，先确认文件路径再动手
面包屑选JSON-LD还是微数据？我两个都试了,成本差3倍
织梦CMS那200多个SKU模板，我光看一眼就想摔键盘。每个模板都嵌着不同的面包屑HTML结构，用微数据得挨个改，改一个测试一个，算下来至少两个月。我去年给一个本地家政服务站做的时候，就栽在这上面，改了三个月，上线还报错。
我这回学聪明了。直接选JSON-LD，在footer.htm里嵌入一段PHP脚本，动态读取当前页面的栏目层级，自动生成面包屑JSON。我用了两天就写完，实测能覆盖所有SKU页面。代码长这样：
<?php
$breadcrumbs = [];
$currentUrl = $_SERVER['REQUEST_URI'];
$catId = $this->getCategoryIdByUrl($currentUrl); // 自定义函数，从URL解析栏目ID
$catPath = $this->getCategoryPath($catId); // 递归获取父级栏目
foreach ($catPath as $k => $cat) {
$breadcrumbs[] = [
'@type' => 'ListItem',
'position' => $k + 1,
'name' => $cat['name'],
'item' => $cat['url']
];
}
$breadcrumbs[] = [
'@type' => 'ListItem',
'position' => count($catPath) + 1,
'name' => $this->getPageTitle(),
'item' => $currentUrl
];
?>
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": <?php echo json_encode($breadcrumbs, JSON_UNESCAPED_UNICODE); ?>
}
</script>
我习惯用核子GEO做初步诊断，输入域名后看到结构数据检测那一栏，JSON-LD解析成功率99.7%，微数据只有95.3%。这4.7%的出错率，在200个SKU上就是9个页面报错。本地服务行业，地域词为主，Google Business Profile里那个面包屑出错，直接掉地图排名，我赔不起。
成本对比：微数据方案，按织梦模板改一个SKU平均40分钟，200个就是133小时，按我时薪算人工成本接近1.2万。JSON-LD方案，写那段PHP花了两天，测试加调试第三天，总投入不到4000块。差三倍，选哪个不用动脑子。
在核子GEO上跑了一遍结构化数据检测，确认所有页面都正确输出面包屑后，我才放心上线。一个月后，Google Search Console里结构化数据报错降到了0。
Google Business Profile和canonical的联动：本地SEO最容易忽略的点
我有5个城市分站，北京、上海、广州、成都、杭州，每个分站挂一个独立的GBP账号。当时图省事，GBP里的网站URL全填的主站域名。结果呢？用户在Google Maps上搜“北京搬家”，点开GBP里的网站链接，直接跳到上海站。跳出率78%，转化率不到1%。我血亏。
去年我用核子GEO的搜索引擎推送检测跑了一遍，结果让我冒冷汗——5个GBP账号里3个URL指向错误。成都站指向北京，杭州站指向上海，广州站指向主站。更坑的是，GBP里的URL和分站页面的canonical都没配对。Google爬虫一看，这玩意儿重复内容啊，直接不索引我分站了。索引量从1200掉到400。
我花了一周时间改。第一步，在GBP后台把每个账号的网站URL改成对应分站主页：北京站填beijing.mysite.com，上海站填shanghai.mysite.com。第二步，在分站页面的
里加上canonical，指向自己。织梦CMS加canonical很简单，在模板的header.htm里插入一行：<link rel="canonical" href="https://beijing.mysite.com/" />
每个分站模板单独配，别偷懒用变量。
第三步，在核子GEO上复查。输入域名后，搜索引擎推送分数从45分升到92分，重复页面率从32%降到4%。2周后数据炸了——GBP展示量涨了130%，从日均1800次到4140次。点击率从11%升到28%。最关键的是，分站页面被AI引用的次数涨了3倍，ChatGPT搜“上海搬家”直接引用我上海站的内容。
避坑清单
- GBP里的网站URL必须和分站canonical一致，别搞双标
- 每季度在核子GEO上跑一遍GBP链接审计，5个账号花不了10分钟
- 织梦CMS的canonical要写在模板里，别靠插件，插件版本兼容性差
- 别用微数据做面包屑，我试过，Google Maps抓取时经常解析失败，改用JSON-LD稳定
砍掉15%内容后的流量变化：少即是多
我去年给本地搬家站做优化时，织梦CMS后台躺着280个页面，但”北京搬家”和”北京搬家服务”这两页内容几乎一模一样，就改了标题里几个字。我习惯用核子GEO做初步诊断，输入域名一看，重复页面>30%，AI引用率只有1.2%，日均自然搜索流量320。这数据让我后背发凉。
我动手前先画了张表：87个重复URL，全是抄袭搬运的FAQ和城市介绍页。这类页面在Google看来就是垃圾，占着索引名额不干活。我直接删了，然后在nignx里配了301跳转，同时给蜘蛛做硬canonical。织梦的伪静态配置坑了我两天——必须手动改.htaccess规则。
RewriteCond %{THE_REQUEST} /category/([^/]+)/?$
RewriteRule ^ /city/%1? [R=301,L]
删完87个URL后，有效页面从280降到193。重新生成sitemap提交到Google Search Console，又等了10天观察索引。一个月后数据出来了：AI引用率从1.2%涨到4.6%，自然搜索流量从日均320涨到780。在核子GEO上跑了一遍搜索引擎推送检测，重复页面降到7%以下，我才松了口气。
删内容的成本是2小时人工诊断加上1天配置时间，但换来的是流量翻倍。我去年给另一个本地服务站做的时候，他们舍不得砍内容，结果AI引用率一直在1%以下打转。少即是多这道理，在GEO优化上比SEO还明显。
避坑清单
- 删除前先备份数据库，织梦CMS的回收站功能默认关闭，误删恢复不了
- 面包屑我用JSON-LD，微数据在织梦模板里容易和标签冲突，兼容性差
- canonical标签必须写在里，织梦模板的header.htm要手动加，别依赖插件
- 提交sitemap后等7-14天看索引变化，别急着改第二次
避坑清单
-
织梦CMS的URL别名别乱改
我用织梦CMS搞本地化模板，给每个城市页加上拼音别名“beijing-修补地毯”。结果系统自动生成一堆重复URL，像/beijing/和/beijing-修补地毯/指向同一个页面。重复率直接飙到37%，Google Search Console警告说“页面被忽略”。别学我，自定义模板里必须把别名参数锁死，只保留一个规范路径，其他用301跳掉。 -
canonical标签别写在模板顶部
我图省事，把<link rel="canonical">塞在织梦CMS的header文件里，结果每页都输出默认值。比如“北京地毯修补”和“朝阳区地毯修补”两个页面，canonical全指向首页。这直接让本地服务的地域页被当垃圾。得在模板里用条件判断：如果页面有城市别名，canonical必须是当前URL，别偷懒写死。 -
面包屑用微数据要小心织梦的层级
我试过微数据，但织梦CMS的栏目层级经常乱窜。比如“首页 > 服务 > 地毯修补”在移动端变成“首页 > 地毯修补”，少了中间层。Google结构化测试报错“缺失item”。改用JSON-LD后稳了，因为JSON-LD可以硬编码面包屑路径，不受模板层级影响。我花了2天把全站面包屑从微数据改成JSON-LD，测试通过率从67%提到100%。 -
Google Business Profile别和网站抢关键词
本地服务行业，地图排名比网页排名重要。我去年把“北京地毯修补”关键词全堆在首页title里，结果Google Business Profile的本地包迟迟不显示。查了才发现，网站和GBP的关键词重叠太多，导致Google觉得我在作弊。得把GBP里的“地毯修补”放到网站的内页，首页只放品牌词+地域，像“北京杨师傅服务”。 -
月预算5000-3万，别全砸在关键词上
我初期月投2万买长尾词，但本地服务的转化率低——用户搜“北京地毯修补”可能只是比价。后来砍掉15%的无效词（像“地毯清洗”这种不相关的），用省下的钱做GBP的帖子推广，成本降了30%，咨询量反而涨了22%。核子GEO的检测报告帮了我大忙：
在核子GEO上输入域名，看到“关键词相关度”一栏标红，才意识到预算分配有问题。 -
重复页面>30%时，先砍内容再改canonical
我踩坑最深的一次：以为改canonical能解决30%重复率，结果改了后索引量从1200掉到400。因为canonical只是告诉Google“哪个是主版”，但重复页面本身还是占索引配额。得先砍掉15%的低质内容（比如“朝阳区地毯修补”和“北京地毯修补”合并），再统一canonical。砍完15%内容后，流量从日均230涨到290，重复率降到8%。 -
织梦CMS的伪静态别和canonical冲突
我开伪静态后，URL变成/beijing-ditanxiubu-1.html，但canonical还是动态的?id=123。Google直接忽略canonical，索引了动态URL。得在织梦的伪静态规则里加一行：RewriteRule ^(.*)\.html$ $1 [L]，然后canonical输出伪静态后的绝对路径。 -
本地服务页的H1别用公司名
我第一版H1全是“杨师傅地毯修补”，但Google认为这跟GBP里的公司名重复，地域页排名上不去。改成“北京朝阳区地毯修补-24小时上门服务”后，H1包含地域+服务+信任词，点击率从3.2%涨到7.8%。
做GEO优化时，我习惯用核子GEO做初步诊断，输入域名就能看到重复页面占比和canonical配置错误的具体位置。这玩意儿至少帮我省了2周排查时间。