谷歌seo怎么优化移动端网站？渐进式网络应用程序（PWA）正在利用新技术将最好的移动网站和本机应用程序带给用户 - 而且它们是网络上最激动人心的新想法之一。但要真正产生影响，重要的是它们是可索引的和可链接的。本文中提出的每条建议都是现有的可索引性最佳实践 - 无论您是构建Progressive Web App还是简单的静态网站。尽管如此，我们整理了这些最佳实践，以提供一份指导您的清单：
使您的内容可抓取
为什么？从历史上看，网站总是在服务器上生成或呈现HTML，这是确保您的内容可直接链接的最简单方法。Web应用程序普及了客户端呈现的概念，其中内容在用户导航时在页面上动态更新，而不需要重新加载页面。
现代方法是混合渲染，其中当用户直接导航到URL并且在初始页面加载之后用于后续导航和异步请求时使用客户端渲染时使用服务器端渲染。
我们的服务器端PWA示例演示了纯服务器端渲染，而我们的混合PWA示例演示了组合方法。
如果您不熟悉服务器端和客户端呈现术语，请在此处和此处阅读这些文章。
最佳实践：
使用服务器端或混合呈现，以便用户在其Web请求的初始有效负载中接收内容。
始终确保您的网址可以独立访问：
wxhl.net/google/
以上内容应与该特定资源紧密相关。
如果您无法支持Progressive Web App的服务器端或混合渲染，并且您决定使用客户端渲染，我们建议您使用Google Search Console“获取Google工具”来验证您的内容是否已成功呈现给我们的搜索抓取工具。
别：
请勿将访问深层链接的用户重定向回您的网络应用主页。
此外，还应避免向用户提供错误页面而不是深度链接。
提供干净的URL
为什么？片段标识符（＃user / 24601 /或＃！user / 24601 /）是浏览器从服务器获取AJAX新内容而无需重新加载页面的有效解决方法。此设计称为客户端呈现。
但是，片段标识符语法与某些Web工具，框架和协议（如Facebook的Open Graph协议）不兼容。
在历史API，使我们没有片段标识符更新URL，同时还获取资源异步模式，因此避免页面重载-这是两全其美。AJAX爬行方案（带有＃！/转义片段URL）在当时是有意义的，但现在不再推荐了。
我们的混合PWA和客户端PWA示例演示了History API。
最佳实践：
提供没有片段标识符（＃或＃！）的干净URL，例如：
wxhl.net/google/
如果使用客户端或混合渲染，请确保使用History API支持浏览器导航。
避免：
使用 ＃！不鼓励驱动唯一网址的网址结构：
wxhl.net/google/
它是在History API出现之前作为解决方法引入的。它被认为是纯粹#URL结构的单独模式。
别：
使用＃URL结构而不附带！符号不受支持：
wxhl.net/google/
此URL结构已经是Web中的一个概念，与深层链接到特定页面上的内容有关。
指定规范URL
为什么？当多个URL（无论是相同或不同的域）下可用相同内容时，消除混淆索引的最佳方法是将一个页面标记为规范，将所有其他页面复制该内容以引用它。
最佳实践：
在镜像特定内容的所有页面中包含以下标记：
<link rel =“canonical”href =“wxhl.net/google//”/>
如果您支持Accelerated Mobile Pages，请务必正确使用其对应的rel =“amphtml”指令。
避免：
避免故意在多个URL中复制内容，而不是使用rel =“canonical”链接元素。
例如，rel =“canonical”链接元素可以减少具有跟踪参数的URL的模糊性。
别：
避免在页面之间创建冲突的规范引用。
多个设备的设计
为什么？重要的是，所有用户在查看您的网站时都能获得最佳体验，无论他们的设备如何。
使您的网站在其设计中具有响应性 - 您的网站的字体，边距，填充，按钮和一般设计应根据屏幕分辨率和设备视口动态扩展。
针对台式机或平板电脑设备放大的小图片会给您带来糟糕的体验。相反，超高分辨率图像需要很长时间才能在手机上下载，并可能影响移动滚动性能。
在此处阅读更多用于PWA的UX。
最佳实践：
使用“srcset”属性为不同的密度屏幕获取不同的分辨率图像，以避免下载大于设备屏幕能够显示的图像。
缩放字体大小和行高，以确保无论设备大小，文本都清晰可辨。同样，确保元素的填充和边距也能合理地缩放。
使用Chrome开发者工具的设备模式功能和移动友好测试工具测试各种屏幕分辨率。
别：
不要向用户显示与向Google展示的内容不同的内容。如果您使用重定向或用户代理检测（也称为浏览器嗅探或动态服务）来更改不同设备的站点设计，则内容本身保持不变非常重要。
使用搜索控制台“抓取为Google”工具验证Google提取的内容是否与用户看到的内容相匹配。
出于可用性原因，请避免使用固定大小的字体。
迭代地发展
为什么？向Web应用程序添加功能时最安全的方法之一是迭代地进行更改。如果您一次添加一个功能，则可以观察每个更改的影响。
另外，许多开发人员更愿意将他们的渐进式Web应用程序视为一次性改造其移动站点的机会 - 在隔离环境中开发新的Web应用程序，并在准备好后将其与现有移动站点进行交换。
在迭代地开发特征时，尝试将更改分解为单独的部分。例如，如果您打算从服务器端渲染转移到混合渲染，那么将其作为单个迭代进行处理 - 而不是与其他功能组合。
这两种方法各有利弊。迭代降低了处理搜索索引性的复杂性，因为转换是连续的。但是，迭代可能会导致开发过程变慢，并且如果开发不是从头开始，则可能会进行较少的创新性改造。
在任何一种情况下，要关注的最敏感区域是您的规范网址和您网站的robots.txt配置。
最佳实践：
通过逐个添加新功能逐步迭代您的网站。
例如，如果不支持HTTPS，则首先迁移到安全站点。
避免：
如果您已在隔离环境中开发了渐进式Web应用程序，则应避免在未检查rel-canonical链接的情况下启动它，并正确设置robots.txt。
确保您的rel-canonical链接指向真实网站，并且您的robots.txt配置允许抓取工具抓取您的新网站。
别：
在启动之前阻止抓取工具为您的开发中网站编制索引是合乎逻辑的，但不要忘记在启动时取消阻止抓取工具访问您的新网站。
使用渐进增强功能
为什么？在可能的情况下，在使用浏览器功能之前检测它们非常重要。功能检测也比测试支持给定功能的浏览器更好。
过去常见的不良做法是通过测试用户使用的浏览器来启用或禁用功能。然而，随着浏览器不断发展的功能，强烈建议不要采用这种技术。
服务工作者是一项相对较新的技术，重要的是不要在追求进步时破坏兼容性 - 这是何时使用渐进增强的完美示例。
最佳实践：
在注册Service Worker之前检查其API的可用性：
if（导航器中的'serviceWorker'）{
...
使用每种API检测方法来处理您网站的所有功能。
别：
切勿使用浏览器的用户代理启用或禁用Web应用程序中的功能。始终检查功能的API是否可用，如果不可用则正常降级。
避免更新或启动您的网站，而无需跨多个浏览器进行测试！检查您的网站分析，了解哪些浏览器在您的用户群中最受欢迎。
使用Search Console进行测试
为什么？了解Google搜索如何查看您网站的内容非常重要。您可以使用搜索控制台来从您的网站抓取单个网址，看看谷歌搜索使用的是如何看待他们“抓取>抓取谷歌”功能。Search Console将处理您的JavaScript并在选择该选项时呈现页面; 否则只显示原始HTML响应
Google Search Console还会以多种方式分析您网页上的内容，包括检测结构化数据，Rich Cards，附加链接和加速移动页面的存在。
最佳实践：
使用Search Console监控您的网站，并探索其功能，包括“抓取为Google”。
通过Search Console“抓取>站点地图”提供站点地图这可以是确保Google搜索了解您所有站点网页的有效方法。
使用Schema.org结构化数据进行批注
为什么？ Schema.org结构化数据是一个灵活的词汇表，用于将页面中最重要的部分概括为可机器处理的数据。这可以像简单地说一个页面是一个新闻文章，或具体到详细说明一个旅游乐队的位置，乐队名称，场地和票务供应商，或总结配方的成分和步骤。
使用此元数据可能对您的Web应用程序中的每个页面都没有意义，但建议在合理的地方使用。Google会在呈现页面后将其提取出来。
有各种数据类型，包括“NewsArticle”，“Recipe”和“Product”等等。在此处浏览所有支持的数据类型。
最佳实践：
使用Google的结构化数据测试工具验证您的Schema.org元数据是否正确。
检查您提供的数据是否显示且没有错误。
别：
避免使用与您网页的实际内容不匹配的数据类型。例如，不要将“食谱”用于您正在销售的T恤 - 请改用“产品”。
使用Open Graph和Twitter Cards进行注释
为什么？除了Schema.org元数据之外，添加对Facebook的Open Graph协议和Twitter富卡的支持也会很有帮助。
当您的内容在相应的社交网络上共享时，这些元数据格式可改善用户体验。
如果您现有的网站或网络应用程序使用这些格式，那么确保它们包含在您的渐进式Web应用程序中以及最佳的病毒式传播方面非常重要。
最佳实践：
使用Facebook对象调试工具测试您的Open Graph标记。
熟悉Twitter的元数据格式。
别：
如果现有站点支持这些格式，请不要忘记包含这些格式。
使用多个浏览器进行测试
为什么？显然，从用户的角度来看，网站在所有浏览器中的行为都很重要。虽然体验可能适应不同的屏幕尺寸，但我们都希望移动网站在类似尺寸的设备上工作相同，无论是iPhone还是Android手机。
虽然由于世界各地使用的浏览器数量，网络可能被视为碎片化，但这种多样性和竞争是使网络成为创新平台的一部分。值得庆幸的是，Web标准从未像现在这样成熟，现代工具使开发人员能够自信地构建丰富的，跨浏览器兼容的网站。
最佳实践：
使用浏览器测试工具（如BrowserStack.com，Browserling.com或BrowserShots.org）确保您的PWA与浏览器兼容。
测量页面加载性能
为什么？网站为用户加载的速度越快，用户体验就越好。优化页面速度已经是Web开发中众所周知的重点，但有时在开发新版本的站点时，必要的优化不被视为高优先级。
在开发渐进式Web应用程序时，我们建议您在启动站点之前测量页面加载速度的性能并进行优化，以获得最佳结果。
最佳实践：
使用Page Speed Insights和网页测试等工具来衡量网站的页面加载性能。虽然Googlebot在渲染方面有一点耐心，但研究表明，40％的消费者会留下一个加载时间超过三秒的页面。
在此处详细了解我们的网页性能建议和关键渲染路径。
别：
避免将优化作为启动后步骤。如果您的网站内容在迁移到新的渐进式Web应用程序之前加载得很快，那么在优化过程中不要退化很重要。
我们希望上面的清单很有用，并提供正确的指导，以帮助您开发具有可索引性的Progressive Web应用程序。
在开始时，请务必查看我们的Progressive Web App可索引性示例，它们演示了服务器端，客户端和混合渲染。与往常一样，如果您有任何疑问，请联系我们的网站管理员论坛。
大多数人都在使用移动设备在Google上搜索。但是，我们的排名系统通常仍然会查看页面内容的桌面版本，以评估其与用户的相关性。当移动页面的内容少于桌面页面时，这可能会导致问题，因为我们的算法不会评估移动搜索者看到的实际页面。
为了使我们的结果更有用，我们已经开始尝试使我们的索引成为移动优先。虽然我们的搜索索引将继续是网站和应用程序的单一索引，但我们的算法最终将主要使用网站内容的移动版本来对该网站的网页进行排名，理解结构化数据，并在我们的网页中显示这些网页的摘要。结果。当然，虽然我们的索引将基于移动文档构建，但我们将继续为所有用户构建出色的搜索体验，无论他们来自移动设备还是桌面设备。
我们理解这是我们索引的一个重要转变，这是我们认真对待的一个。我们将继续在未来几个月内对小规模进行仔细的试验，当我们确信我们拥有出色的用户体验时，我们会加快这一变化。虽然我们只是开始这个过程，但我们提供了一些建议来帮助网站管理员做好准备，因为我们正朝着更具移动性的指数迈进。
如果您有一个响应式站点或动态服务站点，其中主要内容和标记在移动设备和桌面上是等效的，则您不必更改任何内容。
如果您的网站配置中主要内容和标记在移动设备和桌面设备上有所不同，则应考虑对网站进行一些更改。
确保为桌面版和移动版提供结构化标记。
通过在结构化数据测试工具中键入两个版本的URL 并比较输出，站点可以在桌面和移动设备上验证其结构化标记的等效性。
将结构化数据添加到移动站点时，请避免添加与每个文档的特定信息内容无关的大量标记。
使用robots.txt测试工具验证Googlebot是否可以访问您的移动版本。
网站不必更改其规范链接 ; 我们将继续使用这些链接作为指南，为在桌面或移动设备上搜索的用户提供适当的结果。
如果您是仅在Search Console中验证其桌面版网站的网站所有者，请添加并验证您的移动版本。
如果您只有一个桌面版网站，即使我们使用移动用户代理查看您的网站，我们也会继续为您的桌面网站编制索引。
如果您要构建网站的移动版本，请记住，功能性面向桌面的网站可能比网站的损坏或不完整的移动版本更好。建立您的移动网站并在准备好时启动它会更好。
如果您有任何疑问，请随时通过网站站长论坛或我们的公共活动与我们联系。我们预计此更改将需要一些时间，我们会在迁移系统时取得进展。
