WooCommerce分类页URL里塞7段乱码，服务器照样回200还带index

摘要：在17个真实WooCommerce站上做的URL实测里，15个能测通的站有14个接受这样的地址——把商品分类页路径中间塞进7段完全不存在的目录，服务器照样回200，标题、商品列表、robots的index一个不少。根子在WooCommerce给product_cat的rewrite里主动开了层级匹配，而WordPress解析时只取路径的最后一段，前面写什么都不看。

更反常的是同一台服务器上，带问号的那种写法反而会被自动301修正——大家防了十几年的参数URL是安全的，没人防的路径URL才是漏的那个。这篇把7套分类法的注册参数、属性归档那个勾选框背后互相打架的3个默认值，以及一个运费等级怎么变成带CollectionPage标记的落地页，全部摊开讲。

先说一个能立刻上手的动作：打开你自己的WooCommerce站，找一个商品分类页的地址，比如/product-category/shoes/，然后在中间硬塞两段根本不存在的目录，变成/product-category/xyz123/abc456/shoes/，回车。

如果你看到的是完整的分类页，商品都在，标题也对，那你和我测过的绝大多数站在同一条船上。

这件事之所以值得单开一篇，是因为它和大家熟悉的那套筛选器治理完全不是一回事。筛选器URL爆炸是勾选框组合出来的，看得见、算得出、有成熟打法。而这一套是WooCommerce自己注册分类法时的参数决定的，不勾任何东西它就在那儿，而且不在任何后台界面上出现。

WooCommerce到底给你注册了几套分类法？

很多人以为WooCommerce就是商品分类加商品标签两套。实际数一遍源码，光是硬编码写死的就有5个，加上属性那一批动态注册的，一个中等规模的站跑起来通常是七八套起步。

我把WooCommerce 10.8.1的includes/class-wc-post-types.php里register_taxonomies()那个方法逐个参数抄了下来。这个文件不长，但每一行都在决定你的站会不会凭空长出URL。

五个硬编码的分类法，参数差别在哪

看这张表的时候，注意力别放在“写了false”的那三行，那三行是对的。请盯住第四行。

“没写”在WordPress里不等于“关着”

WordPress注册分类法时有一套默认值，public这一项的默认是打开。官方文档在register_taxonomy()那页写得很直白：这个参数决定“分类法是否供公开使用，无论是通过后台界面还是前台用户”，而且publicly_queryable、show_ui、show_in_nav_menus三个参数如果没设，全都跟着它走。

所以省略public这一行的效果，是把这个分类法交给前台。对product_cat和product_tag来说这正是意图。对运费等级来说，这是一次遗漏。

我知道你现在在想什么：运费等级又没有URL，rewrite都写成false了，能出什么事？这个问题的答案在后面第七节，我先把更普遍的那个坑说完。

为什么URL里塞乱码还能返回200？

先看WooCommerce注册product_cat时的rewrite参数：

'rewrite' => array(
    'slug'         => $permalinks['category_rewrite_slug'],
    'with_front'   => false,
    'hierarchical' => true,
),

再看product_tag的：

'rewrite' => array(
    'slug'       => $permalinks['tag_rewrite_slug'],
    'with_front' => false,
),

差别只有一个键：hierarchical。WordPress官方文档对这个键的说明是“是否使用层级重写标签，默认false”——也就是说，层级匹配不是默认行为，是WooCommerce主动开的。对一个真有父子层级的商品分类来说，开它很合理，不然嵌套路径根本生成不出来。

核心就是WordPress里的这三行

问题出在WordPress解析请求的时候。WP_Query在处理分类法查询变量时有这么一段：

if ( is_string( $query_vars[ $t->query_var ] ) && ! empty( $t->rewrite['hierarchical'] ) ) {
    $query_vars[ $t->query_var ] = wp_basename( $query_vars[ $t->query_var ] );
}

wp_basename()做的事情和命令行里的basename一样：把路径切开，只留最后一段。

于是xyz123/abc456/shoes被切成shoes，前面那两段连看都没看。而重写规则那边因为开了层级匹配，正则用的是贪婪的多段匹配，所以任意多段前缀都能被吞进来。两件各自合理的事凑在一起，结果就是同一个分类页有无穷多个能返回200的地址。

同一个站上的对照实验

光有机制推断不算数。我在同一个站（goshopia.com，一个做可持续时尚的独立站）上打了三条地址，同一时段、同一个UA：

同一台服务器、同一套主题、同一个SEO插件，唯一的差别是那一个键。第三条尤其值得看：womenswear和beauty都是这个站真实存在的分类，只是它们跟accessories之间根本没有父子关系。拼在一起，200。

塞7段也照收

我把测试拉到17个站上。这17个站是先用WooCommerce的Store接口确认过确实跑着WooCommerce，再挨个打的。其中2个站被自己的防护挡住（一个限流、一个走了人机验证），剩下15个能测：

• 14个站接受任意前缀并返回200，包括我塞了7段的/a/b/c/d/e/f/g/那种
• 只有1个返回404，那个站把分类的路径前缀设成了空，分类页直接挂在根目录上
• 返回200的这14个里，页面标题、H1、商品列表、结构化数据和真实地址一模一样

换句话说，这不是某个主题或某个插件的毛病，这是WooCommerce加WordPress这套组合的默认形态。

带问号的地址反而被自动修好了，这是怎么回事？

这一节是我做完实测之后，把原本写好的提纲推翻重写的部分。

做SEO的人对?product_cat=shoes这种参数形态有天然的警觉，要不要在robots里屏蔽筛选参数这类问题每年都要吵一轮。我原本以为这次也一样：参数形态漏得更狠，路径形态问题不大。

实测结果正好反过来。

五个站，五次301

我在5个站上分别请求了参数形态的地址，包括?product_cat=、通用的?taxonomy=product_cat&term=，以及属性的?pa_color=：

• 全部返回301，一跳到规范的路径地址
• 没有一个站需要额外配置，这是WordPress核心自带的行为
• 同一批站上，路径形态的乱码地址一次都没被跳转过

原因藏在一个if里

WordPress核心的redirect_canonical()负责这件事。官方文档对它的介绍是“把进来的链接重定向到正确的URL”，还专门解释说这是为了“避免重复内容带来的惩罚”。听上去它应该管住所有变体。

但翻到处理分类法归档的那一支，整段逻辑被包在一个条件里：只有当请求带查询字符串时才往下走。路径形态的地址没有问号，这一整段直接被跳过。

所以真实情况是：WordPress只帮你修它认识的那种重复，而它认识的恰好是大家已经防住的那种。这有点像家里装了防盗门，结果小偷是从没上锁的阳台进来的——门是好门，只是防的方向不对。

这条经验能迁移到别处

比“WooCommerce有个坑”更值钱的是判据本身：凡是平台号称“自动规范化”的能力，都要问一句它规范化的是哪一类变体。参数变体、路径变体、大小写变体、斜杠变体，通常不是一套逻辑在管。这条在重复内容的六类排查里同样成立，只是那篇讲的是判断标准，这里给的是一个具体反例。

真实站点里，这些地址是谁生成的？

到这儿会有个合理的质疑：乱码地址是我手工敲的，Googlebot又不会自己编。这话没错，所以关键问题不是“能不能构造”，而是“实际会不会产生”。

最常见的来源是分类改挂父级

假设你把activewear从womenswear底下挪到sportswear底下。这是运营改品类结构时每季度都会发生的事。

改完之后，get_term_link()生成的新地址是/product-category/sportswear/activewear/。而旧地址/product-category/womenswear/activewear/——按前面那套机制——永远返回200，永远不会404，也永远不会301。

这意味着你的站在改一次品类结构之后，会安静地留下一整套等价地址。没有报错，没有告警，GSC也不会提示你，因为从HTTP层面看什么问题都没有。

其余几个来源

• 只带子分类slug的链接：导航菜单手工填地址、部分区块和小工具按slug拼链接，产生的就是/product-category/activewear/这种没有父级段的形态。实测同样200
• 外部链接：早年被引用过的旧路径，别人的站里还挂着
• 建站期的试验：分类树反复调整时留下的中间态
• 爬虫自己的组合：这一条我保留怀疑，没有日志证据不敢下结论

保哥去年帮一个做户外装备的出海站做架构盘点时就撞上过：他们两年里改过三轮品类树，扒下来的地址里同一个“登山杖”分类挂着4条不同的父级路径，全部200，全部带index。没人做错任何事，机制自己攒出来的。

属性那个“启用归档”的勾选框，为什么一勾就多出一整套URL？

商品属性（颜色、尺码、材质那些）在WooCommerce里也是分类法，前缀统一是pa_。它们的注册方式和前面五个不一样，是根据数据库里那张属性表动态生成的。

勾了之后发生了什么

注册代码里，属性的基础参数是这样：

'query_var' => 1 === $tax->attribute_public,
'rewrite'   => false,
'public'    => 1 === $tax->attribute_public,

然后紧跟着一段覆盖：

if ( 1 === $tax->attribute_public && sanitize_title( $tax->attribute_name ) ) {
    $taxonomy_data['rewrite'] = array(
        'slug'         => trailingslashit( $permalinks['attribute_rewrite_slug'] ) . ... ,
        'with_front'   => false,
        'hierarchical' => true,
    );
}

两个细节值得停一下。

第一，hierarchical又是true——可属性分类法本身是扁平的，它没有父子关系。一个没有层级的分类法配了层级匹配的重写规则，这个组合本身就很奇怪。

第二，属性的路径前缀默认是空字符串。WooCommerce官方文档里给的例子就是这个形态：“如果你启用了它，而'黑色'是'颜色'属性下的一个选项，你就可以把http://yourstore.com/color/black/加到菜单里”。

注意这个地址：/color/black/，直接坐在站点根目录上，和你的/about/、/contact/平起平坐。我在goshopia.com上实测了这个形态，返回200，自指canonical，robots是index, follow，标题是“Black Archives”——一个完整身份就是“黑色”这两个字的可索引页面。

17个站的真实开启率

我把这17个站的属性全拉了一遍，一共67个属性分类法，其中12个开着归档，占17.9%。这12个背后是287个词条，也就是287个前台可达的归档地址。

更有意思的是开关的分布毫无规律可言：

• 有个站14个属性里开了3个：颜色开、印花开、童装尺码开，而成人尺码、材质、产地全关
• 另一个站同时存在Color和Colour两个属性（一个美式一个英式拼写），英式那个开着，美式那个关着
• 还有个站15个属性开了2个，其中一个是“浴缸形状”，7个词条

这不像有人做过决策，更像有人在后台点着点着手滑了。

三个默认值在打架

然后我去追这个开关的默认值到底是什么，追出了一个挺离谱的结果——WooCommerce自己在三个地方给了两个答案：

结论是：你从哪扇门进来，决定了你拿到哪个默认值。走后台界面或者官方接口创建属性，走的是wc_create_attribute()，不勾就是关。而绕过这个函数、直接往属性表里写行的代码——迁移脚本、主题的演示数据导入、批量建站工具——只要没显式给这一列，拿到的就是建表语句里那个1。

一个能对上号的现场

17个站里有一个特别典型。它是做夏威夷植物系护肤的品牌站，3个属性全部开着归档，而且这3条记录的属性标签是空的。

后台界面创建属性时标签是必填的，填不了空。标签为空说明这几行不是从界面进来的。

再看它们的词条：品牌属性下面是zara、h-m、marks-and-spencer，系列属性下面是fall-winter-2013、spring-summer-2014。一个护肤品牌站，挂着一堆快时尚品牌和十几年前的服装季。这是主题演示数据的残留。

而它今天还活着：/collection/fall-winter-2013/返回200，robots是index, follow，canonical指向自己。这个站的商品分类页倒是被认真治理过——分类地址全部301跳到了商店主页。有人花心思清理过分类，没人想起来还有属性这一套。

一个运费等级，怎么变成了带CollectionPage标记的落地页？

现在回到第一节末尾那个悬着的问题：product_shipping_class的rewrite写着false，没有漂亮地址，它能出什么事？

先做对照

WordPress除了漂亮地址，还有一套通用的分类法访问方式：?taxonomy=分类法名&term=词条slug。这条路不需要重写规则，只要这个分类法是可公开查询的就行。

我在两个站上分别请求了四种分类法的通用形态，结果分成清清楚楚的两组：

显式关掉的两个，查询变量被直接丢弃，落回首页。而运费等级返回的是404——404意味着WordPress真的去查了这个分类法，只是我猜的词条不存在。它是活的。

找到一个真实的词条

于是我换了个打法：拿10个常见的运费等级名字（heavy、bulky、standard、fragile、free-shipping之类），在6个站上挨个试，一共60次请求。59次404。第60次，一个南非的精酿啤酒站给了我200。

把这一页扒开看：

• HTTP状态：200
• 标题：Free shipping per product Archives - Cape Brewing Company
• H1：Free shipping per product
• robots：index, follow, max-image-preview:large
• canonical：指向它自己，连问号和参数都完整保留
• 结构化数据：CollectionPage，还配了面包屑
• 页面主体：列着1个商品

把这几行连起来读一遍：一个纯后台的运费配置项，长出了标题、H1、自指canonical、CollectionPage标记和面包屑。SEO插件没做错任何事——它看见一个可公开查询的分类法，就按规矩给了它全套待遇。整条链路上每个环节都在正确执行，错的是最初那个没写出来的参数。

这不是孤例

我顺手搜了一下这种地址形态，翻出了至少3个域名的这类页面已经躺在搜索结果里：一个英国的工程设备站、一个工业水处理设备站（一口气3条，分别是运费等级A、K、P），还有一个航海图表站。标题清一色是“Shipping Class X Archives”。

没有人会搜“shipping class A”，这些页面对谁都没用。它们只是在那儿，占着抓取额度，稀释着站点的主题信号。

更新（2026年7月27日）：WooCommerce在11.0的测试版里给product_shipping_class补上了'public' => false这一行，和另外三个内部分类法对齐了。也就是说这确实是个遗漏，官方后来自己认了。但升到11.0并不会让已经被收录的旧地址消失——那些URL的处置还是得按下面第十节的矩阵来。停留在10.x的站更要自查一遍。

原生的WordPress加WooCommerce，给了归档页多少索引控制？

讲到这里该回答一个基础问题了：这一整套归档体系，平台自己配了什么保护措施？

canonical：归档页一个都没有

WordPress核心输出canonical的函数是rel_canonical()，官方文档对它的定位就一句话：“为单页查询输出rel=canonical”。函数体第一行就是判断，不是单页直接返回。

分类页、标签页、属性归档，全部不是单页。所以核心一个canonical都不给它们。

那WooCommerce补了吗？我在10.8.1完整包的3965个PHP文件里搜rel_canonical，命中0次。

robots：只管三个页面

WooCommerce确实管了robots，但范围小得超出多数人的预期。整个插件里跟robots相关的逻辑只有两处：

• 一处给购物车、结账、我的账户三个页面加noindex
• 一处给订单接收之类的endpoint地址发X-Robots-Tag: noindex响应头

就这些。它造了整套归档体系，却没给这套体系配任何索引策略。这不是批评——插件本来也不该替站长做SEO决策——但它意味着：如果你的站没装SEO插件，或者装了但没配到这一层，那么所有分类页、标签页、属性归档、以及前面那些乱码变体，全都是裸奔的可索引页面。

实测里的两个裸奔样本

17个站里有2个的分类归档完全不输出canonical，robots里也没有任何索引指令，只有一个图片预览的声明。对这两个站来说，/product-category/a/b/c/d/e/f/g/gift-cards/这种地址就是一个独立的、可索引的、和真实分类页内容100%相同的页面，没有任何信号告诉搜索引擎它们是一回事。

另外14个站装了SEO插件，乱码地址上的canonical确实正确地指向了真实地址。这一点必须说清楚，不能吓唬人。但要注意Google对canonical的定位是“一个强信号，表示指定的URL应当成为规范版本”——是信号，不是命令。Google选择canonical的决策逻辑里有一整套自己的判断，你给的只是其中一票。

更重要的是：canonical管的是索引，管不了抓取。爬虫必须先把这个页面下载下来，才能读到里面的canonical。

除了词条本身，还有哪些地址在同一套体系里被复制？

前面算的都是“词条数”，但一个词条从来不只对应一个地址。

先看基数

17个站的分类法词条总量：

那个有2093个商品标签的站，商品分类才65个。标签数是分类数的32倍——这个比例在WooCommerce站上非常典型，因为标签的录入成本几乎为零，而WordPress体系里分类和标签的SEO定位差异又不是每个运营都清楚。

再看每个词条能生出多少地址

我在几个站上把常见的变体形态挨个打了一遍：

feed这一项容易被漏掉。WordPress给每个公开分类法的每个词条都配了一个RSS地址，而实测里这些feed既没有canonical也没有robots标签——它是XML，本来也放不了meta标签。那个有181个分类加689个标签的站，光feed地址就是870个，一个都不在sitemap里，全靠爬虫自己发现。

好消息是有边界。越界翻页和裸前缀都干脆利落地404了，说明WordPress并不是哪里都漏，分类页分页那套机制本身是收敛的。

这套膨胀和大家熟悉的那几种，差在哪？

把边界划清楚，才知道该用哪套工具。

关键差别在“后台可见性”那一行。筛选器和搜索页你至少知道它们存在，索引膨胀的三角诊断法也能把它们扒出来。而分类法这一套，你在WooCommerce后台翻遍所有设置页都找不到“我的站有几套分类法、哪几套对前台开放”这个信息。

那到底该怎么收拾？

先说一句立场：我不建议一上来就大面积noindex。分类页是WooCommerce站最重要的一类着陆页，误伤的代价远高于膨胀本身。

第一步：把家底摸出来

后台看不到，就从别处取。三个来源都不用改代码：

• Store接口：/wp-json/wc/store/v1/products/categories、/tags、/attributes三个地址，不需要登录，直接返回JSON。属性那个接口会带一个字段告诉你归档开没开，这是最省事的自查入口
• sitemap：看SEO插件把哪些分类法放进去了。放进去的说明插件认为该索引，没放的未必就安全
• 日志：按路径前缀分组统计爬虫的抓取次数，能看出爬虫实际在哪些地址上花时间

第二步：按分类法分档处置

属性归档那一行需要展开说。判据是这个属性值本身是不是一个人们会搜的品类词。“黑色”不是，“尺码L”不是；但“Abode”这个水暖品牌是，“防水材质”可能是。前面那个开了品牌属性归档、底下挂着60个品牌词条的英国水暖站，我认为它开得对。

第三步：乱码变体怎么处置

这一类不能照搬前面的手段，因为它们数量无穷，你没法枚举。三条路：

• 确认canonical是对的——这是成本最低也最要紧的一条。装了主流SEO插件的站基本都对，但那两个裸奔的站必须先补上
• 用重写规则做收口——在服务器层判断路径段数，超过分类树实际深度的直接301到规范地址。这条要谨慎，先在测试环境验证，别把合法的三级分类误伤了
• 不建议用robots屏蔽——路径形态没有稳定特征可以匹配，写宽了会连真实分类页一起挡掉，那才是真事故

第四步：知道什么该忍

Google的抓取预算文档有一句话值得反复读：对于那些你不想让它出现在搜索结果里的重复页面，用robots.txt挡住比加noindex更好，因为“Google仍然会请求它，然后在看到noindex标签或响应头之后把这个页面丢掉，浪费了抓取时间”。

这句话点破了一个常见误解：noindex省的是索引，不省抓取。所以对已经被收录的膨胀页面，noindex和canonical怎么组合要按场景判断，加noindex等它掉出索引之后再考虑要不要屏蔽，顺序反了会让页面卡在索引里出不来。

怎么验证治理真的生效了？

这一节给的是可执行的核对清单，不是理论。

三条硬指标

1. 抽10个分类页做前缀测试：治理前全部200，治理后应该301或者维持200但canonical正确。这一步能直接量化
2. 翻爬虫日志按前缀分组：看/product-category/下面的抓取次数占比有没有下降，以及有没有出现路径段数异常多的请求
3. GSC的页面报告按状态分组：重点看“重复，Google选择的规范网址与用户指定的不同”这一类的数量变化，各种未编入索引状态的判定路径不一样，别混着看

时间预期要放平

索引层面的变化不会立刻发生。已经收录的页面加了noindex之后消失需要时间，这个周期跟页面被抓取的频率强相关，冷门页面可能要等好几周。已收录页面加noindex后多久掉出结果那篇里有分场景的实测数据，可以拿去对预期。

别把这件事的收益吹大

说句实在话：对一个只有20个分类、没开属性归档、装了SEO插件的小站，这套问题的实际影响接近于零。canonical会兜住，抓取额度也不紧张。

真正需要动手的是这几类：分类超过100个的、商品标签成千上万的、属性归档开着而且词条很多的、改过品类树的、以及没装SEO插件的。电商站的架构深度本来就影响爬虫能不能走到商品页，再叠上一层等价路径，浪费的额度就不是零头了。

常见问题解答

我怎么在10分钟内判断自己的站有没有这个问题？

三条命令级别的检查。第一，拿一个真实分类页地址，在前缀里塞两段乱码，看是不是200。第二，访问/wp-json/wc/store/v1/products/attributes，看有没有属性的归档字段是开着的。第三，随便打开一个分类页看源码，确认有没有canonical、robots写的是什么。三条都干净就基本不用管了。

这些重复地址还没被收录，是不是就可以不管？

取决于站的规模。没被收录说明canonical在起作用，索引层面是干净的，这是好事。但抓取是另一回事：爬虫得先下载页面才能读到canonical，所以额度已经花掉了。分类和标签词条加起来几百个的站，这点开销可以忽略；上千个词条再叠上feed和变体的，就该看日志算账了。

把商品标签和属性归档全部noindex，是不是最省事的做法？

省事，但有代价。商品标签页在一些站上是真能带流量的长尾入口，尤其是标签命名接近用户搜索词的时候。更稳的做法是按词条下的商品数分档：只挂着1到2个商品的标签页确实没什么内容，可以处理；挂着几十个商品、标题又是个正经品类词的，先别动。一刀切最容易出的事故是把有流量的页面一起关掉，而这种损失往往过两个月才看得出来。

属性归档到底什么情况下值得开？

判据只有一个：这个属性值单独拿出来，是不是一个人们真会去搜的词。品牌属性通常值得开，因为“某某品牌 水龙头”是真实的搜索需求。材质、认证、适用场景这类有时候也值得。而颜色、尺码、重量这些基本不值得——没人会搜“黑色”然后期待落到你的店里。开之前先去关键词工具里查一下那个词的真实搜索量，别凭感觉。

用robots.txt把多层路径挡掉行不行？

不建议。这类路径没有稳定的特征可以写进匹配规则，你没法用一条规则区分“三级真实分类”和“两段乱码加一个分类”。写窄了挡不住，写宽了会把真实的嵌套分类页一起挡掉，那是比膨胀严重得多的事故。这一类更适合在服务器的重写规则层按路径段数做判断，而且必须先在测试环境验证。

换一个SEO插件能解决吗？

能解决一部分。主流插件都提供按分类法开关索引的设置，也都会给归档页补canonical，这两件事确实是插件在做而不是WooCommerce在做。但插件的设置界面通常只列出它认识的那几套分类法，属性那一批pa_开头的经常不在默认名单里——我实测的一个站就是商品标签被设成了noindex，而属性归档照样index, follow。换插件之前先把自己有几套公开分类法数清楚，比换插件本身重要。

权威参考资料