页内锚点三成指不到目标，点下去地址栏变了页面不动

摘要：131个电商站的181个页面上一共2801条井号开头的页内链接，其中84.1%连名字都没写，是纯占位。真正写了名字的443条里，有142条在本页找不到目标，用了页内锚点的88个站里有32个中招。这些链接不会出现在任何一份死链报告里。死链工具按惯例整类跳过它们，搜索引擎索引时又会把井号后面那截砍掉，于是它们在所有监控口径里都不存在。分档之后更有意思：58.5%是第三方组件留的钩子，41.5%是自己写坏的，其中24条是把CSS转义的反斜杠原样粘进了链接地址。

页面上有一类链接，点下去不换页。它以井号开头，后面跟一个名字，意思是请滚到这一页上叫这个名字的那块地方去。目录跳章节、页脚跳到顶部、商品页跳到评价区，用的都是它。

这类链接的目标不在别的服务器上，就在同一份HTML里。按理说这应该是最不容易坏的一种链接：同一个人写的页面，同一个模板输出的内容，指的还是自己。

结果呢，它坏起来没人知道。上一篇量的是这一页上的名字重没重，这一篇量的是另一头：指过去的那个名字，在不在。

点一个井号开头的链接，浏览器到底做什么？

HTML规范里滚动到片段那一节把这个动作拆成了4步，按顺序试：

1. 在文档里找id等于这个名字的元素，找到就用第一个；
2. 找不到，就找name属性等于这个名字的a元素，找到就用第一个；
3. 还找不到，如果这个名字正好是top，就用文档根元素，也就是回到页首；
4. 都不是，返回空——什么都不做。

第四步是本文的主角。什么都不做的意思是：地址栏会变，页面不会动，控制台不会有任何输出。浏览器认为这是完全合法的一次导航，它只是没找到落点而已。

这个静默还有几重加成。搜索引擎索引URL时会把井号后面那截整个砍掉，同一页的10条锚点在爬虫眼里是同一个地址，所以它们永远不会以404的形式出现在任何一份报告里。死链检测工具那篇里写得明明白白，工具会跳过4类地址，纯锚点排在第一位，理由是页内跳转探活没有意义。至于用户，点了没反应通常会归因为自己没点准，不会去报。

于是这一类链接同时躲开了机器和人这2条监控线。

这一轮量了什么？

取的是131个电商站，每站首页一份，其中56个站另取一个商品页，一共187个页面，用真浏览器打开、等待、滚到底再滚回来才读。200且解析成功的181个页面，来自127个站。

读法是：把页面上所有a标签的href取出来，只留2种：直接以井号开头的，以及解析成绝对地址之后前半截跟当前页完全一样、只多一个井号的。后一种容易被漏掉，模板里拼绝对地址是很常见的写法。

拿到名字之后先解一次URL编码，再按规范那4步走一遍：查id、查a元素的name、判断是不是top。都不中就记为找不到目标。

有件事得交代。同一批页面前后跑了2趟，第二趟修了一个口径错误，顺带把锚点也重读了一次。2趟数字不完全一样：页内锚点2860对2801，找不到目标的144对142，差异来自页面本身在2次抓取之间的微小变化，不是脚本读法变了。下面凡是锚点与引用属性的数字一律用第二趟，其余的沿用第一趟。

2800条页内锚点，84.1%连名字都没写

84.1%的井号链接根本不是链接。它们的href就是一个孤零零的井号，真正干活的是绑在上面的脚本：点了之后打开抽屉、展开菜单、弹出弹层、切换标签页。井号在这儿只起一个作用：让这个东西看上去像个链接，能被键盘聚焦、能有手型光标。

这2355条里有604条带着role属性，也就是写页面的人已经用ARIA告诉辅助技术这其实是个按钮或者标签页；另有31条挂着onclick。剩下的既没有role也没有onclick，行为完全由外部脚本绑定。过时HTML标签实测那篇讲的是老写法怎么在换平台时被原样搬过来，用a标签加井号冒充按钮属于同一类惯性，只是它老得没那么显眼。

数量分布很极端。everlane.com的首页一页就有387条纯井号占位，商品页393条；liquiddeath.com的2个页面各202条；jackery.com首页和商品页各95条，一条具名的都没有。这些站上，几乎每一个可交互的元素都是用a标签加井号搭出来的。

这种写法的代价不在SEO，爬虫根本不会把它当成一条待抓的链接。Google关于可抓取链接的说明里明确要求href指向真实地址，一个孤立的井号显然不是。代价在别处：AI代理只能猜着用你的站那篇量过，代理判断一个元素能不能点、点了会发生什么，靠的就是标签语义和ARIA角色。一个href只有井号、又没写role的a标签，在代理眼里是一条不知道通向哪里的链接，它多半会试着跟过去，然后什么都没发生。

写了名字的那些，有多少能指到东西？

剩下443条具名锚点，这才是真正想用页内跳转的那部分。

还有一个数字没进表：第一趟量的时候顺手统计过，指得到的那些里有8条指向的是一个重名的id，也就是落到了第一个同名元素身上，这一档的后果上一篇讲透了。

32.1%指不到，这个比例本身就够高了。但真正要看的是表里第三、四行：规范里那条备用路径，也就是用a元素的name属性接住的那条，在这批站上一条都没派上用场。老写法确实已经退出历史舞台了，现在这件事100%押在id上。

32.1%指不到，而老写法一条都没派上用场

把死锚点按站排一下，前几名分别是mackweldon.com 32条、charleskeith.com 24条、everlane.com 12条。这3个站合起来68条，占了全部死锚点的47.9%。问题不是均匀分布的，它扎堆在少数几个站上。

另一头也得说：taylorstitch.com的24条具名锚点全部指得到，theordinary.com的7条、bollandbranch.com的7条、gymshark.com的6条也都是满分。这件事是能做对的。

指不到的那批，是第三方组件的钩子还是自己写坏的？

32%这个数很容易被读成10条里有3条是坏的。实际情况要复杂一层，得先分档。

把142条死锚点按名字里有没有第三方组件的标记拆开：

第三方那一档长这样：mackweldon.com页脚上那一整套会员中心入口，井号rivo、井号rivo-orders、井号rivo-profile、井号rivo-logout，一共32条，全是某个积分插件的锚点约定；6个站的收藏夹入口写着井号swym-wishlist；3个站的登录入口写着井号k-hub；awaytravel.com、flyingtiger.com和ugreen.com的隐私设置写着井号reopenBanner。

这一档不完全算bug。这些名字是插件跟自己约好的信号：脚本在页面上监听点击事件，看到这个名字就自己去把对应的面板造出来。目标在加载完那一刻确实不存在，但用户点下去多半是有反应的。

但它有2个真实代价，而且都能量出来。这83条里有33条是当场可见能点的，一旦那个插件的脚本没加载上，被广告拦截器挡掉也好，被内容安全策略拦掉也好，网络慢了没到也好，用户点的就是一个纯粹的死链接。第三方脚本拉进来的那些域名那篇数过一个页面上能有多少个外部域名要谈成，这里每一条都是一个成败点。而且这些约定还会自己变，两天半里就有四分之一的站被第三方悄悄改了。今天对得上的名字，下个月不一定还对得上。

另一个代价落在不执行脚本的读者身上，包括相当一部分抓取器和代理，这些链接从头到尾就是死的。智能体读的是无障碍树不是截图，而无障碍树上这条链接是存在的、有名字的、看起来可以跟过去的。

自己写的那59条，集中在几个不常被点的入口上

这59条有个规律，高度集中在同一类功能上：隐私选择、评价区、收藏、快速预览、跳过导航。也就是那些不是每天都被点、但一旦被点就说明用户真的在找它的入口。

brooklynbedding.com的页脚上有一条写着不出售不共享我的个人信息，指向井号do-not-sell-or-share-my-personal-info，当场可见，目标不存在。这是美国部分州法律要求必须提供的入口。reebok.com和nativecos.com的同类入口分别指向井号showCB和井号onetrust-modal，也都指不到。那2个是同意管理平台的钩子，属于上一档。

graza.co和wusthof.com的商品页上，评价区那条井号product-reviews指不到。用户看到4.9分4542条评价，点一下，页面不动。

一个反斜杠是怎么把24条锚点一起弄死的？

charleskeith.com那24条值得单独拿出来讲，因为它是一个特别干净的因果链。

它的商品页上每张商品卡都是一个小轮播，左右2个箭头，箭头是页内锚点，指向轮播容器的id。地址写成这样：

<a href="#product-tile-carousel-CK2-30671782-1_STO\.GR_XL">Previous</a>

注意点号前面那个反斜杠。这是CSS选择器的转义写法。在选择器里，点号表示类名，要匹配一个名字里真的带点号的id，就得写成反斜杠加点号。

问题是这一截是URL的片段，选择器那套转义规矩在这里不作数。URL里的反斜杠就是一个普普通通的字符，它成了名字的一部分。页面上那个容器的真实id是不带反斜杠的，于是浏览器按带反斜杠的名字去找，找不到。

脚本核实过：把反斜杠去掉之后，这24条全部能指到本页的元素。它们不是名字写错了，是名字写对了但多带了一层转义。

怎么就写成这样了呢？八成是有人在浏览器控制台里调这个轮播，用CSS选择器定位到了容器，把选择器字符串复制出来当成了id值，粘进了模板。这类错误在带点号、冒号、方括号的id上特别容易发生，商品SKU里带点号是很常见的事。商品标识码那篇里也提过同一类麻烦：一个标识符长什么样，取决于它被放进了哪个系统。

另有一类邻近的：beistravel.com、fahertybrand.com、mackweldon.com、rothys.com、untuckit.com这5个站的15条死锚点，名字在本页找不到对应的id，却能找到同名的class。第三方组件的钩子约定的是类名，写模板的人当成id写进了链接地址。类名和id长得一样、写法只差一个符号，混起来毫不费力。3万条!important那篇翻过这批站的样式表，类名的数量比id还多一个数量级，两边撞脸是迟早的事。

有人在井号后面写了一整个网址

剩下的死锚点里，有几条坏的方式完全不一样。

decathlon.com的页脚上有一条社交媒体链接，锚文本写着自家的Instagram账号，地址是这样的：

<a href="#https://www.instagram.com/decathlonusa/">@DecathlonAmerica</a>

整个网址前面多了一个井号。浏览器于是老老实实在本页找一个叫https://www.instagram.com/decathlonusa/的元素，找不到，不动。这条链接当场可见、锚文本正常、在页脚上挂着，唯一的问题是它一辈子也去不了Instagram。

philips.com的页脚上有2条我的飞利浦入口，地址是井号tab=sign-up.html。这看着像有人把查询参数的写法和片段的写法搞混了，也可能是某个老系统里的路由约定被原样搬了过来。

everlane.com的首页上有4条社交内容位，锚文本是网红的账号名，地址是井号pdpOverlay=加商品标识。这个是故意的，把片段当状态参数在用，脚本读到这段就知道该弹哪个商品的浮层。这种写法本身能跑，代价是这4条链接对任何不执行脚本的读者都是死的，而且地址栏里会留下一串外人看不懂的东西。

glossier.com的一条更像手滑：href写的是井号加Opens Findation，Opens Findation是这个按钮的行为描述，本该出现在无障碍标签里，结果出现在了地址里。

这几条的毛病是一样的。它们全都不算逻辑错误，错在内容被放进了错误的格子。井号后面那一截没有任何格式校验，写什么进去都不会报错。SEO爬虫报的死链和Googlebot抓的不是同一批那篇讲过地址被解析错会走到什么地步，这里是同一个道理的页内版本：写坏了没人拦，只有真去走那一趟才知道。

跳过导航那条链，97.5%真跳得到

页内锚点里有一条特别重要，就是跳过导航。它通常是页面上第一个可聚焦的元素，平时藏着，用键盘按一下Tab就冒出来，点了直接跳到正文，让不用鼠标的人不必每页都从头听一遍导航菜单。

这条链接是纯粹的页内锚点，也是最容易在改版中被弄断的一条，因为它指向的那个正文容器的id经常跟着模板一起换。

这是全场做得最好的一项，97.5%。3个例外是insta360.com的井号maincontent、snowpeak.com的井号main-navigation-content、baseus.com的井号MainContent，其中baseus那条当场可见。

baseus那条尤其典型：MainContent这个名字是Shopify默认主题里正文容器的id，主题换了或者容器被改名之后，跳过导航那条链接留在原地没人动。无障碍改造那份清单里跳过导航排得很靠前，它属于加一次就再没人回头看的那类改动，而这一类恰恰最需要回归检查。62个站的前端库版本中位停在四年前，说明这类一次性动作在这批站上普遍缺乏复查机制。

那把尺子第一次量出来的数，为什么是错的？

页内锚点只是按名字指认的一种。页面上还有一批属性也在干同样的事：标签的for指认输入框，aria-labelledby指认说明文字，aria-controls指认被这个按钮控制的面板，输入框的form指认它属于哪张表单。这些指认断掉的后果和死锚点是同一类。

第一遍写脚本时，我把所有这些属性的值统一按空格拆成了若干个名字，逐个去查。跑出来的结果是：label的for有49.1%指不到东西。将近一半的标签是断的，这数字大得吓人，也很适合当标题。

然后去翻明细，看见了这几行：for指向&、for指向1、for指向2、for指向3、for指向Vanilla。

问题就在这儿。这些属性分2类，一类是空格分隔的名字列表，另一类只接受一个名字。aria-labelledby、aria-describedby、aria-controls、aria-owns和表格的headers属于前者，写成2个名字就是同时指2个元素。而label的for、输入框的form、input的list、aria-activedescendant只接受一个名字，值里就算有空格，那也是名字本身的一部分。

改对之后，49.1%变成了0.2%

把for当成列表拆，for等于Color Vanilla就被拆成了Color和Vanilla，2条都查不到，失败率凭空翻了几倍。改对之后重新跑：

最后那一行还需要解释一句。MDN关于label元素的说明里写着，标签和控件有2种关联方式：一种是用for指名字，另一种是直接把控件包在标签里面。2种都算数，而且包裹这种不需要名字。3279条for里指不到的307条，其中299条的标签本身就把控件包着，关联照样成立。真正谁也关联不上的只有8条，来自4个站。

结论就这样从一半的标签是断的，变成了标签这件事这批站做得相当好。

顺带一个副产品：3279条for里有734条，也就是22.4%，指向的名字里带着空格。按规范说id不能含空白字符，这734条全是违规写法，但它们绝大多数都指得到。浏览器按字符串原样匹配，不在乎里面有没有空格。上一篇里也跑过这个实验，结论一致：规范违反、功能不坏。

label和aria指认的那些名字，有多少是空的？

把口径改对之后，10种按名字指认的属性一起排出来是这样：

先说一句口径。哪些属性接受多个名字、哪些只接受一个，写在WAI-ARIA 1.2规范里，上一节那个错就是没照着它分类造成的。下面这张表全部按正确的分类重算过。

aria-labelledby的失败率是这批属性里最高的之一，四分之一指不到，而它是可及名称计算里优先级最高的一步。它指空了，元素就退回去用aria-label或者原生标签，退不到就没有名字。132个首页里有28个是空壳那篇量过拿不到名字的元素有多少，这张表补上了另一半原因：名字是写了的，只是指到了空处。

再看aria-owns，只有25%指得到，而且指到的那些100%当场看不见。40条里最常见的目标叫predictive-search-results，出现在7个站上，是Shopify默认主题搜索建议的容器，用户不打字它就不存在。同一个名字在aria-controls那边也有6个站在指。这一档跟死锚点里的第三方钩子是同一个性质：约定成立，只是加载完那一刻还没兑现。

还有指到的目标当场看不见这一列，普遍在七成以上，label的for更是高达95.3%。这个数字不代表出错。大部分标签本来就是给读屏软件用的，视觉上用占位符代替，藏起来是有意为之。51个站的邮箱框只有6个把四件事写全那篇拆过这类框到底说清楚了什么，这里只补一句：藏起来的标签只要关联对了就是有效的，关联错了才是问题。

标签那一头还有23.7%是纯装饰

还有一个从标签那头数的数字。181个页面上一共4565个label：只写for的52.2%，只靠包裹的4.6%，两样都有的19.5%，两样都没有的1081个，占23.7%。这最后一档是纯装饰：它长得像标签、读起来像标签，但没有任何一个控件跟它挂钩。收邮箱那张表一半没写去向那篇是从表单这一头数的，两头的数字合在一起才是完整的账。

结构化数据那边也一样。商品页的结构化数据里一半找不到哪个节点是这一页，用的也是同一套按标识符互相指认的机制，只不过换了一层，那里的名字叫@id，指空了同样不报错。

长文这一头还有个数字。这181个页面上，h2有1992个，带id的256个，只有12.9%；h3是13.2%，h1只有3.9%。H1排第几那篇数的是标题的视觉层级跟标记对不对得上，这里数的是同一批标题有没有留下可以被指认的落点，两件事都缺，长文就没法被切片。标题不挂id，页内跳转就没有落点，段落级深链也无处可指。文章目录怎么挂锚点那篇给的命名规范正是为这件事准备的。当然还有另一条不需要id的路子。MDN讲的文本片段靠匹配可见文字定位，Google搜索结果里那个Read more链接用的就是它，2条路各有各的前提。

照着改，先动哪几处？

这套自查比上一篇还便宜，一行代码，跑完直接得到清单。

[...document.querySelectorAll('a[href^="#"]')]
  .map(a => a.getAttribute('href').slice(1))
  .filter(t => t && t !== 'top' && !document.getElementById(decodeURIComponent(t)));

返回的每一个名字都是本页指不到的目标。拿到清单之后，我自己的处理顺序是这样。

第一步，先挑当场可见能点的。142条死锚点里48条是当场可见的，这48条是用户真的会点到的。看不见的那些多半藏在弹层里，等弹层打开时脚本已经把目标造好了，优先级低一档。

第二步，把第三方组件的钩子单独放一栏，不要当bug改。名字里带插件标识的那些，积分、收藏、同意管理、在线客服，它们的目标本来就是点了才造。该做的是确认那个脚本被拦掉的时候，这个入口有没有降级方案。最简单的降级是把href换成真实地址，让脚本在有能力接管时再阻止默认行为。

第三步，专门查一遍转义。名字里出现反斜杠的，几乎一定是从CSS选择器里复制出来的；出现http开头的，是整条网址被塞进了片段；出现等号的，多半是有人拿片段在传参数。这3种模式用正则一扫就出来，是所有死锚点里最好修的。

转义、跳过导航、合规入口，这三处优先

第四步，单独验一次跳过导航。它平时不可见，改版时最容易被落下，而它坏掉的代价比其他任何一条都大。验法是按Tab让它显形，点一下，看页面动没动。

第五步，把法律和合规相关的入口过一遍。隐私选择、不出售个人信息、无障碍声明这几类，在实测里的失败率明显偏高，原因是它们大多由第三方接管、又极少被点开验证。

第六步，如果你的页面上有大量纯井号占位的a标签，至少给它们补上role属性。这不影响现有脚本，但能让读屏软件和代理知道这是个按钮不是链接。语义化标签那篇讲过标签选错的代价，这里是最省力的一种补救。

保哥的经验是，这套检查真正的价值不在当下能修几条，而在它能查出另一件事，一个站的页内锚点坏得越多，说明它的模板换过的次数越多，而换模板时被落下的东西绝不止锚点这一样。mackweldon.com那32条会员中心入口全部指不到，翻开一看是整套积分插件的前端约定跟当前主题对不上——那不是32个bug，那是一次没做完的迁移。

常见问题解答

页内锚点指不到目标，会影响SEO吗？

不会直接影响，搜索引擎索引URL时会把井号后面那截砍掉，同一页的所有锚点在爬虫眼里是同一个地址，所以它们不会以死链形式出现在任何报告里。间接影响有2条：一是页面内导航是段落级深链的落点，锚点断了搜索结果里的章节跳转就无处可指；二是读无障碍树的AI代理会把这些链接当成可跟随的入口，跟过去什么都没有。

怎么一次查出本页所有指不到目标的锚点？

在控制台里把所有以井号开头的a标签的href取出来，去掉井号，排除空值和top，再逐个用getElementById查一遍，查不到的就是死锚点。注意要先对名字做一次URL解码，因为模板里带中文或者特殊字符的名字会被编码。

href只写一个井号算不算错？

语法上没错，但它称不上一条链接。实测里84.1%的页内锚点是这种纯占位写法，2355条来自52个站，真正干活的是绑在上面的脚本。代价是辅助技术和AI代理会把它当成一条通向未知地址的链接。如果这个元素的实际行为是按钮，正确做法是用button标签；改不动的话至少补一个role属性说明它是什么。

为什么死链检测工具查不出页内锚点的问题？

因为工具按惯例整类跳过它们。纯锚点、JavaScript伪链接、邮件链接、电话链接这4类都不会被发请求探活，理由是它们不是HTTP资源，探活没有意义。这个设计对前3类是对的，唯独页内锚点留下了盲区。它确实需要验证，只是验证方式得换一个，不发请求，在本页查名字。

第三方插件留的锚点指不到，需要修吗？

不按bug修，但要做一件事：确认脚本被拦掉时这个入口有没有降级方案。实测里58.5%的死锚点属于这一档，其中33条是当场可见能点的。这些名字对应的面板由插件脚本在点击时现场创建，脚本一旦没加载上，广告拦截器、内容安全策略、网络超时都可能，用户点到的就是一条纯粹的死链接。

id里带点号或者冒号，锚点该怎么写？

直接原样写进井号后面就行，URL片段部分不需要转义点号和冒号。需要转义的是CSS选择器。在选择器里点号表示类名，所以要用反斜杠转义。这2个场景的规则不一样，把选择器的写法复制进href是实测里最常见的一种错，一个站上就有24条锚点栽在这里。

跳过导航的链接怎么验证还有效？

打开页面直接按Tab键，第一个显形的元素通常就是它，点一下看页面有没有跳到正文。这条链接平时不可见，改版换主题时最容易被落下，实测里65.2%的页面有它，97.5%指得到，剩下的失败案例全都是主题里正文容器的id变了，链接留在原地没人改。

权威参考资料