Front-End-Checklist 规则精讲杜绝 HTTPS 页面指向 HTTP 的协议降级链接https-downgrade【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist本文围绕开源仓库 Front-End-Checklist 中的https-downgrade技能与规则文档展开系统讲解HTTPS 页面不得链接到 HTTP 目的地这一技术 SEO 规则的检查方法、修复步骤、代码示例与验证手段。读完本文你将掌握如何审计站点内外部链接的协议一致性、在 HTTP→HTTPS 迁移中批量修复硬编码 URL以及在代码评审阶段用源码级手段拦截http://链接与资源。规则源文档位于 skills/https-downgrade/SKILL.md配套的完整实现细节与代码示例见 skills/https-downgrade/references/rule.md正文内容对应规则库中的 packages/content/rules/en/seo/https-downgrade.mdx。规则速览Quick Reference在仓库的规则元数据中packages/content/rules/en/seo/https-downgrade.mdx的 frontmatter该规则被归类为分类seo、子分类technical、优先级medium、难度intermediate、预估耗时 10 分钟。技能文件 skills/https-downgrade/SKILL.md 的description明确指出其适用场景审计站点的内部与外部链接是否协议一致将站点从 HTTP 迁移到 HTTPS审查代码库中可能硬编码了http://而非https://的 URL。核心结论速览HTTPS 页面上的所有内部链接必须指向 HTTPS URL——HTTP 链接会触发混合内容mixed content警告指向 HTTP 目的地的外部链接会打破安全链并可能被浏览器拦截内部链接应使用协议相对 URL//example.com或绝对 HTTPS URL——切勿硬编码http://。为什么 HTTPS 页面不能链接到 HTTP协议降级的技术本质当页面通过 HTTPS 提供服务时该页面上的每个链接和资源也应当使用 HTTPS。规则文档skills/https-downgrade/references/rule.md明确将协议不一致定性为既是信任问题也是技术 SEO 问题。具体危害体现在四个方面1. 浏览器拦截主动混合内容被直接封锁现代浏览器会直接封锁主动混合内容active mixed content——即从 HTTPS 页面加载的 HTTP 脚本、样式表等。这类资源被封锁意味着功能静默失效例如统计脚本不加载、样式丢失而页面本身不会给出明确报错排查成本极高。2. 用户警告降低信任度页面存在混合内容时浏览器会显示安全警告用户可能因此放弃访问或对站点产生不信任。这在登录、支付等高信任场景下影响尤其明显。3. 重定向开销拖慢页面加载HTTPS 页面上的 HTTP 内部链接意味着每次导航都会多一次重定向HTTP 301 → HTTPS。若链接指向http://yoursite.com/about而目标实际在 HTTPS 上浏览器必须先请求 HTTP 再跟随重定向到 HTTPS额外增加一次往返延迟累积起来显著拖慢全站浏览体验。4. 排名信号折损HTTPS 已被确认为 Google 排名因素仓库规则文档references/rule.md中引用了 Google Search Central 的 HTTPS ranking signal 指南与 MDN 的混合内容参考文档作为标准依据。当链接从 HTTPS 页面跨到 HTTP 目的地时通过链接 referrer 传递的排名信号会被削弱——安全上下文降级搜索引擎无法完整确认链接的传递价值。此外规则文档还提示这类协议不一致问题在站点迁移期间常常与 sitemap-domain 问题 一起出现审计时应一并排查。检查清单扫描 HTTPS 页面上的全部 HTTP 链接在 HTTPS 服务的页面上需要扫描所有a href属性中以http://开头而非https://的 URL并分三类标记内部链接使用http://应改为https://或相对路径外部链接指向仍运行在 HTTP 上的第三方站点标记待人工复核——目的地可能不支持 HTTPS资源链接img src、script src、link href指向 HTTP URL这些会造成主动混合内容警告。代码评审Code Review阶段的检查面更广规则文档要求解析所有a href、img src、script src和link href属性标记任何以http://开头的值排除https://和相对路径。在 JavaScript 框架中还需检查fetch()、axios以及路由跳转调用里是否硬编码了http://。最终按类别内部、外部、资源统计 HTTP 链接数量并输出报告。修复方案从 HTTP 到 HTTPS 的七步改造SKILL.md与规则 mdx 的fixprompt 给出了完整可执行的七步修复流程这里逐条展开审计所有模板与内容中的a href值先全局搜索所有http://链接建立完整清单再动手修复内部链接将http://yourdomain.com/path改为/path相对路径或https://yourdomain.com/path处理外部链接逐个确认目的地是否支持 HTTPS支持则更新为https://若第三方站点仍不支持 HTTPS应记录在案并评估影响必要时改用其他提供方或自托管修复资源链接脚本、样式、图片等资源一律使用https://或协议相对//CMS 或数据库批量替换对数据库中存储的历史内容执行全局搜索替换把存量 HTTP URL 批量升级为 HTTPS配置服务器级 HTTP→HTTPS 重定向兜底捕获用户生成内容UGC中残留的 HTTP URL——即使内容里写的是 HTTP用户访问时也能被 301 重定向到 HTTPS验证修复效果用grep -r hrefhttp:// ./templates/或链接审计工具复查确认没有遗漏。代码示例错误与正确写法以下示例来自 skills/https-downgrade/references/rule.md是修复时的直接参考模板。❌ 错误HTTPS 页面上的 HTTP 链接!-- 页面实际通过 https://yoursite.com 提供服务 -- a hrefhttp://yoursite.com/aboutAbout Us/a !-- 触发重定向传递错误的协议信号 -- a hrefhttp://partner.example.com/offerView Offer/a !-- 混合上下文浏览器可能警告 --第一个链接是典型的内部链接协议错误第二个是外部链接协议错误。❌ 错误HTTPS 页面上的 HTTP 资源!-- 这些会被现代浏览器直接拦截 -- script srchttp://cdn.example.com/analytics.js/script img srchttp://images.example.com/logo.png altLogoscript属于主动混合内容被浏览器静默封锁img属于被动混合内容在严格模式下同样会被封锁。✅ 正确相对路径或 HTTPS 链接!-- 内部链接优先使用相对路径 -- a href/aboutAbout Us/a !-- 内部链接必要时使用绝对 HTTPS -- a hrefhttps://yoursite.com/aboutAbout Us/a !-- 外部链接确认目的地支持 HTTPS 后再使用 -- a hrefhttps://partner.example.com/offer relnoopener noreferrerView Offer/a !-- 资源一律 HTTPS -- script srchttps://cdn.example.com/analytics.js/script img srchttps://images.example.com/logo.png altLogo注意外部链接示例同时添加了relnoopener noreferrer这是跨站链接的安全最佳实践。✅ 协议相对 URL遗留方案!-- 协议相对继承页面自身协议 -- !-- 注意现代代码中更推荐显式 https:// -- script src//cdn.example.com/script.js/script规则文档特别说明协议相对 URL 是一种遗留legacy方案在支持显式https://的现代代码中应优先使用显式协议写法。内容类型与风险等级references/rule.md给出了各类资源的风险等级对照表这是判断修复优先级的核心依据资源类型风险等级浏览器行为script srchttp://...严重Critical静默拦截link hrefhttp://...CSS严重Critical静默拦截img srchttp://...警告Warning严格模式下被拦截a hrefhttp://...导航警告Warning目标支持 HTTPS 时被重定向修复优先级建议优先处理两张严重级别的行——脚本和样式表被封锁是功能性问题统计失效、样式丢失而图片和链接大多还能通过重定向或升级机制兜底。如何定位残留的 HTTP 链接命令行扫描# 在 HTML 模板中查找 HTTP 链接 grep -rn hrefhttp:// ./src/templates/ grep -rn srchttp:// ./src/templates/如果需要更广的覆盖HTML/CSS/JS 全类型文件规则库中同族的 mixed-content 规则 提供了扩展版扫描命令grep -r http:// ./src --include*.html --include*.css --include*.js --include*.jsx --include*.tsx # 聚焦资源属性 grep -rE srchttp://|hrefhttp://|url\(http:// ./src浏览器端脚本在浏览器 DevTools → Console 中直接运行Array.from(document.querySelectorAll(a[href^http://])) .map(a a.href)修复完成后打开 DevTools → Security 标签页确认不再有混合内容警告。典型残留位置根据同族规则的总结HTTP URL 常藏身于四处HTML 模板script、link、img、iframe属性、CSS 文件background-image、import、font-face中的url()、JavaScript硬编码的 API 端点与 CDN URL、CMS 内容数据库中存储的旧 HTTP 资源地址。这四点与https-downgrade的检查范围完全互补可作为全面审计时的对照清单。仓库中的相关规则与延伸阅读https-downgrade不是孤立的检查项规则库将其与以下规则建立了关联见packages/content/rules/en/seo/https-downgrade.mdx的relatedRules字段https 规则前置条件HTTPS 是安全上下文的基础优先级为 critical。服务器级 HTTPS 配置301 重定向、有效证书是本规则成立的前提——如果站点本身没有完整启用 HTTPS先按该规则完成全站 HTTPS 化再来处理链接协议问题mixed-content 规则同族问题与https-downgrade同属安全/传输族优先级 high。它补充了主动/被动混合内容的完整分类、Content-Security-Policy: upgrade-insecure-requests指令的兜底方案以及 Chrome 81 对被动混合内容自动升级的行为细节sitemap-domain 规则 与 broken-links 规则三者同处seo/technical领域站点迁移期间通常一起审查。从仓库结构看该规则在 README.md 的规则清单第 438 行和 docs/generated/rules-catalog.md第 328 行中均有收录描述统一为检测 HTTPS 页面指向 HTTP 目的地的链接这类链接会触发混合内容警告并丢失排名信号。此外技能文件体系skills/还为该规则提供了面向 LLM/Agent 的结构化可执行版本元数据标明source: frontendchecklist.io、分类seo、优先级medium。补充upgrade-insecure-requests兜底方案对于数据库中存在大量存量 HTTP 资源 URL、无法立即逐一改写的场景同族的 mixed-content 规则 提供了一种浏览器级兜底——Content-Security-Policy: upgrade-insecure-requests指令会让浏览器在发起请求前把所有 HTTP 子资源自动升级为 HTTPSContent-Security-Policy: upgrade-insecure-requests注意这只是兜底而非根治——它不修改你的 HTML仅做最后时刻的浏览器端升级如果资源本身没有 HTTPS 版本即使加上该指令依然会失败。正确的做法仍然是更新源 URL 为 HTTPS即https-downgrade的修复步骤。对资源缺失 HTTPS 版本的情况mixed-content规则的建议是自托管该资源或更换提供方。例外情况references/rule.md明确列出了该规则的三类例外避免审计时误报无需排名的页面staging、工具类、登录、账户或站内搜索等页面如果本来就不打算参与排名可以有意识地使用不同的抓取/索引信号迁移中间态临时迁移状态会产生噪声化的中间信号——应标记线上生产 URL 的最终形态而不是把一次性过渡产物当成阻塞项信号冲突时取强信号当重定向、canonical、robots 指令或索引性信号相互冲突时应先修复最强的最终信号而不是把每个下游症状都当作独立的阻塞项上报。此外https 规则 也提醒本地开发或仅内部使用的环境可以有所不同但面向生产用户的流量应严格满足传输要求某个主机名、子域或 CDN 边缘路径上的失败对用户和爬虫而言都是真实的失败。验证与验收修复完成后需要按以下方式验收依据references/rule.md的 Verification 章节自动化检查检查渲染后的 HTML 与 HTTP 响应头确认预期的元数据/可抓取性信号真实存在在部署后对具有代表性的页面集重新抓取re-crawl可用 Google Search Console 或等效工具测试受影响的 URL。手动检查使用浏览器 DevTools → Security 标签确认无混合内容警告残留确认改动没有产生冲突的 canonical、robots 或结构化数据信号——例如批量替换 URL 后确保 canonical 与重定向目标一致避免出现 canonical 指向 HTTP、页面却返回 HTTPS 的矛盾状态。小结https-downgrade是 Front-End-Checklist 中成本低、影响面大的一类技术 SEO 规则一次全站的grep扫描加上 CMS 批量替换就能消除浏览器警告、砍掉每次导航的多余重定向并保住 HTTPS 安全上下文下完整的排名信号传递。执行时记住三个层次——资源优先脚本/样式被封锁是功能问题、内部链接用相对路径、外部链接先验证再升级并善用同族的 https 与 mixed-content 规则补齐前置配置与兜底方案即可完成一次干净的协议一致性治理。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考