在考虑迁移财富 100 强公司网站的很大一部分时，我们发旧部分进行重定向。 在第一种情况下，开发人员的日程安排非常紧张，并且通过标准框架、内容交付网络 (CDN) 和 JavaScript 的巧妙组合来解决规模问题，以实现一些个性化。
否则，我们考虑
半开玩笑地建议客户端指向我们服务器上的旧子域，并且我们将构建一个重 企业电子邮件列表 定向引擎（这将具有类似的扩展问题）。 所有这些的问题是缺乏用于重定向的缓存解决方案。缓存配置中的每个步骤都设计得很糟糕，无法缓存 HTML 页面以外的任何内容。 在详细介绍之前，先看一个非常快速的 CDN 入门知识。
对于高度可用的网站或
大量视频/流媒体内容的提供商来说，构建网站与将网站提供给所有需要 导的反移民自由党 它的人是分开的。 CDN 试图消除这个问题，并提供一个独立于底层服务器优雅的内容交付的附加前端。实际上发生的情况是，一家公司将其网站提供给 CDN，然后 CDN 复制该网站并将其提供给客户 – 提供了在不更改底层托管的情况下扩展到数百万用户的能力。
Duncan 不久前写了一篇文章，
内容是从 SEO 角度来看，当他们从本地服务器地理交付内容以向用户提供服务时可能出现的问题。 CDN 如何破坏 SEO 工作 上周我们发现（至少某些）CDN 只缓存“200 OK”状态的 HTML 页面。这意味着当发生大规模 資料庫數據 架构更改时，CDN 没有多大用处，因为（在 SEO 友好的情况下）将有大量 301 重定向从您的小型根服务器提供服务，或者（似乎更有可能）将出现 404 错误，其中 CDN 认为没有页面，因为它已从分页中删除了第 200 页。
最终结果是无法提供
重定向服务。 这是有道理的 – 您当然可以看到 CDN 的要求如何包括仅缓存成功交付的页面并检查基础服务器的每种错误情况（特别是在推出期间，您希望 404 错误能够被捕获并逐步修复，并且您希望 CD4 反映这些修复。例如在 Google Analytics 中）。
相对容易看出这如何演变为拒绝缓存任何非 200 状态页面，但它对于 SEO 目的来说肯定不是理想的。 但更糟糕的是 – 因为当您查看主要框架中内置的大多数缓存解决方案时，您会意识到它们中的大多数对于缓存重定向的设计也很糟糕。每当对不存在的页面发出请求时，它不仅会错过缓存，而且通常会在堆栈中向上传播，直到出现涉及某些数据库查询的真实“不，绝对不存在”（或“永久重定向到那里”）响应。