几个月前,我从一个共享的LAMP主机上移动了一批WordPress网站,并将Cloudflare Pages作为静态输出.
投出是显而易见的:没有PHP进程可以保持补丁,没有MySQL可以守护,有效的免费托管,默认情况下在万事前有一个CDN.
投球没有告诉你 有多少小的,无聊的东西 在路上打破。
这篇文章记录了实际发生的错误, 东京,我会用它作为具体的例子—— 以及我如何解决每个问题。
办法 迁移本身在概念上很简单:爬行活的WordPress站点,将每个URL保存为静态的HTML文件外加其资产,并从Cloudflare Pages中为那棵树服务.
我用一个组合和一个自定义的爬行器 在一些网站 窒息了基于查询-字符串的活页。
静态输出随即被推入 。
没有建设步骤,没有框架,只是文件.
这个简单正是它看起来风险很低的原因。
事实并非如此。
问题1: 相对的犬科标记把一切都指向主页 我部署后注意到的第一件事是Google搜索控制台开始将大多数内页报告为"重复,Google选择了不同的犬类"——它选择的犬类是主页.
一旦我找到它,原因就几乎很有趣:WordPress主题在几个缓存的页面片段中作为相对路径发布的,而不是像.这样的绝对URL.
在最初的WordPress安装上,这并不重要,因为页面本身在缓存点正确解决了相对的引用.
一旦HTML被冷冻并静地服务于不同来源结构(Pages服务于从上到下的一切),每有一页,相对的cononical就倒塌到站根.
修补是一个直截了当但又乏味的通关:将每个导出 HTML 文件复制为 ,并将任何相对或根相通的 href 重写成一个完全合格的绝对URL,与该页自己的路径相匹配.
我写了一个小的脚本,走过导出目录,解析了"犬"标记,并根据文件本身相对于站点根的位置取而代之.
在整个10个站点的运行中,都发现了3个站点中的同一个窃听器——它不是一个燃烧的绊脚石。 tokyo特有怪异,是少数网站共享的插件组合.
问题2:没有sitemap.xml幸存了导出WordPress sitemap插件(我正在使用通用的SEO插件所内置的XML sitemap)从PHP端点动态生成他们的sitemap,而不是作为主题中任何地方的静态文件或上传目录.
一个只跟随链接的镜像爬行是永远不会发现的,除非它从一个页面中被明确链接,通常它不是——它是从"搜索控制台"中被引用并直接提交到"搜索控制台".
结果:在切换后,新静态站点上的 sitemap.xml 要么完全缺失,更糟糕的是,仍然引用已经不存在的旧动态URL作为生成的端点.
对几个网站来说,这几乎被忽略了两周,因为网站仍然排在已索引的网页上;失败模式是沉默的。
我最终通过直接走出导出的文件树(每个文件成为条目),而不是试图保存插件的输出,从而在事实发生后重新生成了站点映像,因为插件的输出不再有任何运行来生产.
这也意味着在"搜索控制台"中为每个地产重新提供新的站点地图,这值得明确而非假设爬行者会有机地取出变化.
问题3:编程JS和CSS 404s WordPress使用并加载大多数主题和插件资产,这些功能经常附加一个版本查询字符串,比如.
一个天真的镜像工具,它处理和作为不同的资源,会保存一个和引用另一个,或者保存查询字符串版本,并根据爬行顺序将无扩展基路径留下未解决.
我看到这批是404的 在Pages的部署日志 用于图像懒惰的脚本和一个肛门