【发布时间】：2019-02-04 16:58:56
【问题描述】：
我们正在使用提供断开链接报告的 CMS；然而，这个损坏的链接报告对我们来说毫无用处，因为它检测到大约 1,300 个损坏的链接，因为它们是我们网络应用产品中许多不同屏幕的深层链接。 （即，静态 HTML 页面链接到需要我们的创作工具无法处理的身份验证的 Web 应用程序，因此它将链接标记为已损坏 - 404。）
理想情况下，我们可以依靠 CMS 报告断开的链接，而且我知道有效的一件事是使用 onclick 事件而不是 href。但我想知道我们是否有理由不这样做。
诚然，我已经阅读了很多关于 onclick="function()" 的类似问题的帖子，但它们似乎都与我们试图完成的任务有所不同。
可以为这些链接使用 onclick 事件而不是标准 href 吗？ （见下面的代码。）
如果这样做，我们会遇到什么问题或限制？ （例如，我不确定我们是否能够测试这些 onclick 链接是否真的有效，至少不能通过自动链接检查器进行测试，这可能没问题。）
是否有其他选项可以让这些链接被损坏的链接爬虫/检查器跳过？
我希望更好地了解这里的最佳做法。
谢谢
<a href="[[relative path to web app]]" class="uxlink">Link Text</a>
<span onclick="location='[[relative path to web app]]'" class="uxlink">Link Text</span>
【问题讨论】：
-
对我来说，你试图修复错误的东西。通过使用 onclick，你也失去了右键单击链接并在新标签中打开的能力，我认为这对那些使用屏幕阅读器等的人来说是不好的。对我来说，问题是您的后端报告 404，而不是 401。401 会向爬虫指示页面退出，但您未获得授权，因此它不是损坏的链接。
-
我完全同意，@Keith！谢谢你。更多信息：当内容发布到其最终目的地时会返回 401，但 CMS 及其源代码控制功能无法返回任何类型的自定义 http 消息，这在这里真的很糟糕。如果我针对我发布的输出运行损坏的链接爬虫，我会看到这些链接的 401。但就编辑工作流程而言，如果我们能够在流程的早期而不是在发布时捕获真正的 404 错误会更好（这需要修复然后重新构建）。希望这是有道理的！
-
听起来切换到 onclick 重定向的唯一要点是让 CMS 的链接检查器跳过这些链接，而不是尝试测试它们；您能否改为将您的 CMS 配置为忽略内部链接？或者，如果它不是那么可配置的，那么在将其传递给人类之前对其输出进行后处理以删除这些内部链接？这似乎比仅仅为了适应不适当的链接检查器而降低用户体验更可取......
-
@DanielBeck 你是正确的。对于一个有点愚蠢的问题，这是一个笨拙的解决方案。不幸的是，CMS 及其源代码控制程序无法忽略某种类型的链接。你能详细说明你的第二个建议吗？通过后处理步骤，是否建议在 CMS 中围绕这些链接使用某种标记标志，然后在 CMS 外部使用脚本或转换来为最终用户正确构建链接？
-
是的，就是这样；如果 CMS 无法配置且无法修改，则不要直接查看 CMS 的输出，而是在其上运行辅助脚本，该脚本将删除与相对路径匹配的行，并查看 its 输出反而。 （并考虑更换那个 CMS，但我相信你已经想到了：）
标签： javascript html