人经常在不同程度上利用AJAX(异步Javascript和XML)框架从SPA迁移到SPA(单页应用程序)。
在企业SEO中,任何人都会在某个时刻遇到与客户端一起出现的此Web体系结构场景。像React,Vue和Angular之类的框架使Web开发变得更加简单。当利用现代浏览器的功能来呈现客户端代码(JavaScript)来创建动态Web应用程序时,尤其是当创建动态Web应用程序以提供相对较快的新请求交互性。使用Web Worker提供不需要传统基于服务器的URL调用的网络请求功能。
随着功能和部署功能的增加,随之而来的是SEO的问题。这让从事SEO的营销者多少有些不知所措。
为什么会出问题呢?
我们都知道,失去的自然排名意味着失去自然流量。问题在推荐JavaScript(JS)框架的Web开发人员通常不直接负责长期的商业表现,技术人员认为随机的自然流量通常被认为不可控制。
SEO已经在尝试处理有史以来投入最大的商业算法中的大量信号。从传统的服务器渲染网站(如Wikipedia)迁移到现代框架可能会给SEO带来很多挑战。
搜索引擎机器人的爬行,渲染和索引编制-Googlebot之类的搜索引擎爬行器已对其爬行过程进行了调整,以包括JavaScript渲染,以便能够完全理解AJAX网页上的代码。Google在理解复杂的JavaScript方面越来越出色。其他搜索爬虫可能做不到。
爬行整个网络绝非易事,甚至Google的资源也很有限。他们必须根据可能在遇到和呈现JS之前很久就发生的假设(例如估算的总页数,域历史记录,WhoIs数据,域权限等指标)来确定网站是否值得进行爬网和呈现。
Google爬行和渲染过程的渲染/索引阶段
速度 – AJAX应用程序最大的障碍之一。Google会对未缓存的网页进行爬网,因此单页应用程序的那些繁琐的首次加载可能会出现问题。速度可以通过多种方式定义,但是在这种情况下,与资源较少的HTML页面相比,我们要讨论的是执行和关键地呈现JavaScript重页面上的所有资源所花费的时间。
- 资源和渲染 –使用传统的服务器端代码,基本上在CSSOM(CSS对象模型)形成后即渲染DOM(文档对象模型),或者更简单地说,DOM不需要在操作之后进行过多的操作。获取源代码。有一些警告,但可以肯定地说,客户端代码(以及可能从中派生代码的多个库/资源)为最终的DOM增加了复杂性,这意味着搜索搜寻器和客户端设备都需要更多的CPU资源。这是为什么不希望使用复杂的JS框架的最重要原因之一,但是经常被忽略。
- 所有内容都假设这些AJAX页面的构建没有考虑SEO。这对于现代Web设计代理机构或内部开发人员来说有点不公平。通常有一些考虑因素可以减轻对SEO的负面影响。我们中间经验丰富的读者现在将开始感到自己遇到了熟悉的领域。
创建AJAX应用程序的解决方案本身就陷入了竞争,这些解决方案的工作方式更类似于SEO的基于服务器的HTML。主要与其功效有关。我们如何测试任何东西对SEO的功效?我们必须部署和分析关键词排名的更改。迁移到JavaScript框架的结果与流量下降反复相关。
AJAX相关的SEO缓解的不同解决方案
1,通用/同构JS
同构JavaScript(也称为AKA通用JavaScript)描述了同时在客户端和服务器上运行的JS应用程序,例如客户端或服务器可以执行<script>和其他传递的代码,而不仅仅是客户端或服务器。通常,复杂的JavaScript应用程序只能在客户端(通常是浏览器)上执行。同构Java脚本可以缓解这种情况。
- 客户端向您的应用程序服务器请求特定的URL。
- 服务器将请求代理到呈现服务,该服务是在Node.js容器中运行的Angular应用程序。该服务可以(但不一定)与应用程序服务器位于同一台计算机上。
- 应用程序的服务器版本为请求的路径和查询提供完整的HTML和CSS,包括用于下载客户端Angular应用程序的<script>标记。
- 浏览器会收到该页面,并可以立即显示内容。客户端应用程序异步加载并准备就绪,重新呈现当前页面,并用呈现的服务器替换静态HTML。现在,对于任何向前推进的交互,该网站的行为都像SPA。对于浏览网站的用户来说,此过程应该是无缝的。
在请求之后,服务器将呈现JS,并形成完整的DOM/CSSOM并将其提供给客户端。这意味着已经向Googlebot和用户提供了页面的预渲染版本。对于用户而言,不同之处在于,然后重新渲染刚投放的HTML和CSS,以将其替换为动态JS,因此其行为可以像预期的SPA一样。构建同构网页/应用程序的问题似乎只是实际上构建事物并不容易。
2,动态渲染
动态渲染是一个更简单的概念。它是检测发出服务器请求的用户代理并基于来自经过验证的漫游器或用户的请求路由正确的响应代码的过程。
这是Google建议的处理用于搜索的JavaScript的方法。这里有很好的说明:
Google解释的动态渲染过程
输出是针对搜索搜寻器的代码的预渲染迭代,以及将始终提供给用户的相同AJAX。Google建议使用诸如prerender.io之类的解决方案来实现这一目标。这是一种反向代理服务,可预先渲染和缓存您的页面。但是必须理解动态渲染的一些陷阱:
- 隐形 -在万维网主要由HTML和CSS为主,伪装是因为谷歌而言一个巨大的负面远。除了尝试对搜索结果进行游戏处理外,没有其他理由检测并向Googlebot提供不同的代码。在JavaScript世界中,情况并非如此。Google的动态渲染过程是直接推荐的伪装。他们明确地说,“为用户服务一件事,为我们服务另一件事”。为什么这是个问题?Google表示:“只要您的动态渲染产生相似的内容,Googlebot就不会将动态渲染视为伪装。”但是有什么相似之处?向Googlebot注入比向用户显示的内容更多的内容,或者使用JS延迟为用户删除文本或以Googlebot不太可能看到的另一种方式操纵页面的可能性有多么容易(例如,由于DOM中的延迟)。
- 缓存 –对于经常变化的网站(例如大型新闻发布者,要求其内容尽快索引),预渲染解决方案可能不会削减它。不断添加和更改页面几乎需要立即进行预渲染,以便立即生效。prerender.io的最短缓存时间以天为单位,而不是分钟。
- 框架千差万别 –每个技术堆栈都不相同,每个库都增加了新的复杂性,每个CMS都将以不同的方式处理这一切。诸如prerender.io之类的预渲染解决方案并不是获得最佳SEO性能的一站式解决方案。
3,CDN带来额外的复杂性(或与此相关的任何反向代理)
内容交付网络可以通过向反向代理网络添加另一层来创建其他测试复杂性。由于Cloudflare通过反向DNS查找阻止未经验证的Googlebot请求,因此测试动态渲染解决方案可能会很困难。因此,对动态渲染问题进行故障排除需要花费时间。让Googlebot重新抓取页面,然后结合Google的缓存和新的有问题的Search Console来解释这些更改。Google的移动友好型测试工具是一个不错的选择,但是您一次只能分析一个页面。
如何才能实现最佳SEO性能呢?
明智地思考并有效地计划。幸运的是,在考虑Web设计领域时,只有相对少数的设计元素对SEO至关重要,其中许多是<head>和/或元数据中的元素。他们是:
- <head> – <link>标记和<meta>标记中的所有内容
- 标头标签,例如<h1>,<h2>等
- <p>标签和所有其他副本/文本
- <table>,<ul>,<ol>和所有其他可爬网HTML元素
- 链接(必须是具有href属性的<a>标记)
- 图片
上面的每个元素都应在没有客户端要求的任何JS渲染的情况下提供。一旦要求呈现JS来产生上述元素之一,就会使搜索性能处于危险之中。JavaScript可以并且应该用于增强您网站上的用户体验。但是如果将其用于将上述元素注入DOM中,那么您将遇到需要缓解的问题。
内部链接通常在Javascript框架内提供最大的SEO问题。这是因为有时会使用onclick事件代替<a>标记,因此不仅仅是Googlebot渲染JS以在DOM中形成链接的问题。即使在渲染JS之后,仍然没有<a>标记可进行抓取,因为根本没有使用它–而是使用onclick事件。
每个内部链接都必须是带有href属性的<a>标记,其中href属性包含链接目标的值,才能被视为有效。
小结
我们可以使用React/Angular,因为我们有next.js / Angular Universal,所以没有问题。一切都需要测试,并且测试过程本身可能很棘手。因素再次无数。举一个极端的例子,如果客户端从一个简单的HTML网站转到一个AJAX框架,该怎么办?客户端渲染关键元素的额外处理和可能出现的问题可能会导致巨大的SEO问题。即使是最小的爬网,索引编制和性能下降,也可能导致可观的收入损失。
不可避免地要避免使用现代JS框架,这不应该成为目标-开发时间节省下来的时间本身可能价值数千美元。但作为SEO,我们有责任大力保护最关键的SEO元素并确保它们始终是服务器面以一种或另一种形式呈现。让Googlebot尽量减少爬行阻力,以理解您的内容。这应该是SEO的目标。