\n (PWAs) are taking advantage of new technologies to bring the best of mobile sites and native
\n applications to users—and they’re one of the most exciting new ideas on the web. But to truly
\n have an impact, it’s important that they’re indexable and linkable. Every recommendation presented
\n in this article is an existing best practice for indexability—regardless of whether you’re
\n building a Progressive Web App or a simple static website. Nonetheless, we have collated these
\n best practices to provide a checklist to guide you:\n<\/p>\n
![](\"https:\/\/alienroad.com\/wp-content\/uploads\/kb-gorsel\/g-6e2e3b503915.jpg\")
<\/p>\n
Make Your Content Crawlable<\/h2>\n
\n Why?<\/b> Historically, websites would always generate or render their HTML on the server which
\n is the simplest way to ensure your content is directly linkable. Web applications popularised the
\n concept of client-side rendering in which content is updated dynamically on the page as the users
\n navigates without requiring the page to be reloaded.\n<\/p>\n
\n The modern approach is hybrid rendering, in which server-side rendering is used when a user
\n navigates directly to a URL and client-side rendering is used after the initial page load for
\n subsequent navigation and asynchronous requests.\n<\/p>\n
\n Our \n If you are unfamiliar with the server-side<\/b> and client-side<\/b> rendering terminology, Best practices:<\/b><\/p>\n \n Use server-side or hybrid rendering so users receive the content in the initial payload of their \n Always ensure your URLs are independently accessible:\n <\/p>\n \n The above should deep link to that particular resource.\n <\/p>\n \n If you can’t support server-side or hybrid rendering for your Progressive Web App and you decide \n Don’t redirect users accessing deep links back to your web app’s home page.\n <\/p>\n \n Additionally, serving an error page to users instead of deep linking should also be avoided.\n <\/p>\n<\/div>\n \n Why?<\/b> Fragment identifiers ( \n However, the fragment identifier syntax isn’t compatible with some web tools, frameworks and \n The History API<\/a> enables \n Our hybrid PWA and client-side PWA samples<\/a> Best practices:<\/b><\/p>\n \n Provide clean URLs without fragment identifiers ( \n If using client-side or hybrid rendering be sure to support browser navigation with the History \n Using the \n It was introduced as a workaround before the advent of the History API. It is considered a \n Using the \n https:\/\/www.example.com\/#product\/25\/\n <\/p>\n \n This URL structure is already a concept in the web and relates to deep linking into content on a \n Why?<\/b> The best way to eliminate confusion for indexing when the same content is available Best practices:<\/b><\/p>\n \n Include the following tag across all pages mirroring a particular piece of content:\n <\/p>\n \n If you are supporting Accelerated Mobile Pages be sure to correctly use its counterpart \n Avoid purposely duplicating content across multiple URLs and not using the \n For example, the \n Avoid creating conflicting canonical references between your pages.\n <\/p>\n<\/div>\n \n Why?<\/b> It’s important that all your users get the best experience possible when viewing your \n Make your site \n Small images scaled up for desktop or tablet devices give a poor experience. Conversely, super \n Read more about Best practices:<\/b><\/p>\n \n Use \n Scale your font size and line height to ensure your text is legible no matter the size of the \n Test \n Don’t show different content to users than you show to Google. If you use \n Use the Search Console “Fetch as Google” tool to verify the content fetched by Google matches \n For usability reasons, avoid using fixed-size fonts.\n <\/p>\n<\/div>\n <\/p>\n \n Why?<\/b> One of the safest paths to take when adding features to a web application is to make \n Alternatively many developers prefer to view their progressive web application as an opportunity \n When developing features iteratively try to break the changes into separate pieces. For example, \n Both approaches have their own pros and cons. Iterating reduces the complexity of dealing with \n In either case, the most sensitive areas to keep an eye on are your canonical URLs and your site’s Best practices:<\/b><\/p>\n \n Iterate on your website incrementally by adding new features piece by piece.\n <\/p>\n \n For example, if don’t support HTTPS yet then start by migrating to a secure site.\n <\/p>\n<\/div>\n Avoid:<\/b><\/p>\n \n If you’ve developed your progressive web app in an isolated environment, then avoid launching it \n Ensure your rel-canonical links point to the real site and that your robots.txt configuration \n It’s logical to prevent crawlers from indexing your in-development site before launch but don’t \n Why?<\/b> Wherever possible it’s important to detect browser features before using them. Feature \n A common bad practice in the past was to enable or disable features by testing which browser the \n Service Worker is a relatively new technology and it’s important to not break compatibility in the Best practices:<\/b><\/p>\n \n Before registering a Service Worker check for the availability of its API:\n <\/p>\n \n Use per API detection method for all your website’s features.\n <\/p>\n<\/div>\n \n Never use the browser’s user agent to enable or disable features in your web app. Always check \n Avoid updating or launching your site without testing across multiple browsers! Check your site \n Why?<\/b> It’s important to understand how Google Search views your site’s content. You can use \n Google Search Console also analyses the content on your page in a variety of ways including Best practices:<\/b><\/p>\n \n Monitor your site using Search Console and explore its features including Fetch as Google.\n <\/p>\n \n Provide a sitemap via Search Console Crawl ><\/span> Sitemaps<\/b>. \n Why?<\/b> Schema.org<\/a> structured data is a \n The use of this metadata may not make sense for every page on your web application but it’s \n There are a variety of data types including Best practices:<\/b><\/p>\n \n Verify that your Schema.org meta data is correct using Google’s \n Check that the data you provided is appearing and there are no errors present.\n <\/p>\n<\/div>\n \n Avoid using a data type that doesn’t match your page’s actual content. For example don’t use \n Why?<\/b> In addition to the Schema.org metadata it can be helpful to add support for Facebook’s \n These metadata formats improve the user experience when your content is shared on their \n If your existing site or web application utilises these formats it’s important to ensure they are Best practices:<\/b><\/p>\n \n Test your Open Graph markup with the \n Familiarise yourself with \n Don’t forget to include these formats if your existing site supports them.\n <\/p>\n<\/div>\n \n Why?<\/b> Clearly from a user perspective it’s important that a website behaviors the same \n While the web can be perceived as fragmented due to number of browsers in use around the world, Best practices:<\/b><\/p>\n \n Use cross browser testing tools such as \n Why?<\/b> The faster a website loads for a user the better their user experience will be. \n When developing a progressive web application we recommend measuring the performance of your page Best practices:<\/b><\/p>\n \n Use tools such as \n Read more about our web page performance recommendations and the \n Avoid leaving optimization as a post-launch step. If your website’s content loads quickly before \n We hope that the above checklist is useful and provides the right guidance to help you develop \n As you get started, be sure to check out our \n
\n server-side PWA sample<\/a>
\n demonstrates pure server-side rendering, while our
\n hybrid PWA sample<\/a>
\n demonstrates the combined approach.\n<\/p>\n
\n check out these articles about
\n client and server side rendering<\/a>, and
\n server side rendering in react and node.js.<\/a>\n<\/p>\n
\n web request.\n <\/p>\n
\n to use client-side rendering, we recommend using the Google Search Console “Fetch as Google
\n tool” to verify your content successfully renders for our Search crawler.\n <\/p>\n<\/div>\n
<\/p>\nProvide Clean URLs<\/h2>\n
#user\/24601\/<\/code> oder #!user\/24601\/<\/code>) were an
\n effective workaround for browsers to AJAX new content from a server without reloading the page.
\n This design is known as client-side rendering.\n<\/p>\n
\n protocols such as Facebook’s Open Graph protocol<\/a>.\n<\/p>\n
\n us to update the URL without fragment identifiers while still fetching resources asynchronously
\n and therefore avoiding page reloads—it’s the best of both worlds. The AJAX crawling scheme
\n (with its #!<\/code> \/ escaped-fragment URLs) made sense at its time, but is now no longer
\n recommended.\n<\/p>\n
\n demonstrate the History API.\n<\/p>\n#<\/code> oder #!<\/code>) such as:\n <\/p>\n
\n API.\n <\/p>\n<\/div>\nAvoid:<\/h3>\n
#!<\/code> URL structure to drive unique URLs is discouraged:\n <\/p>\n
\n separate pattern to the purely #<\/code> URL structure.\n <\/p>\n<\/div>\n#<\/code> URL structure without the accompanying !<\/code> symbol is
\n unsupported:\n <\/p>\n
\n particular page.\n <\/p>\n<\/div>\n
<\/p>\nSpecify Canonical URLs<\/h2>\n
\n under multiple URLs (be it the same or different domains) is to mark one page as the canonical,
\n and all other pages that duplicate that content to refer to it.\n<\/p>\n
\n rel=\"amphtml\"<\/code> instruction as well.\n <\/p>\n<\/div>\nAvoid:<\/h3>\n
\n rel=\"canonical\"<\/code> link element.\n <\/p>\nrel=\"canonical\"<\/code> link element can reduce ambiguity for URLs with
\n tracking parameters.\n <\/p>\n<\/div>\n
<\/p>\nDesign for Multiple Devices<\/h2>\n
\n website, regardless of their device.\n<\/p>\n
\n responsive in its design<\/a>
\n —fonts, margins, paddings, buttons and general design of your site should scale dynamically
\n based on screen resolutions and device viewports.\n<\/p>\n
\n high resolution images take a long time to download on mobile phones and may impact mobile scroll
\n performance.\n<\/p>\n
\n UX for PWAs<\/a>.\n<\/p>\n
\n srcset<\/code> attribute<\/a>
\n to fetch different resolution images for different density screens to avoid downloading images
\n larger than the device’s screen is capable of displaying.\n <\/p>\n
\n device. Similarly ensure the padding and margins of elements also scale sensibly.\n <\/p>\n
\n various screen resolutions<\/a>
\n using the
\n Chrome Developer Tool’s Device Mode<\/a>
\n feature and
\n Mobile Friendly Test tool<\/a>.\n <\/p>\n<\/div>\n
\n redirects or user agent detection<\/a>
\n (a.k.a. browser sniffing or
\n dynamic serving<\/a>) to alter the
\n design of your site for different devices it’s important that the content itself remains the
\n same.\n <\/p>\n
\n the content a user sees.\n <\/p>\nDevelop Iteratively<\/h2>\n
\n changes iteratively. If you add features one at a time you can observe the impact of each
\n individual change.\n<\/p>\n
\n to overhaul their mobile site in one fell swoop—developing the new web app in an isolated
\n environment and swapping it with their existing mobile site once ready.\n<\/p>\n
\n if you intend to move from server-side rendering to hybrid rendering then tackle that as a single
\n iteration—rather than in combination with other features.\n<\/p>\n
\n search indexability as the transition is continuous. However, iterating might result in a slower
\n development process and potentially a less innovative overhaul if development is not starting from
\n scratch.\n<\/p>\n
\n robots.txt configuration.\n<\/p>\n
\n without checking the rel-canonical links and robots.txt are setup appropriately.\n <\/p>\n
\n allows crawlers to crawl your new site.\n <\/p>\n<\/div>\n
\n forget to unblock crawlers from accessing your new site when you launch.\n <\/p>\n<\/div>\n
<\/p>\nUse Progressive Enhancement<\/h2>\n
\n detection is also better than testing for browsers that you believe support a given feature.\n<\/p>\n
\n user had. However, as browsers are constantly evolving with features this technique is strongly
\n discouraged.\n<\/p>\n
\n pursuit of progress—it’s a perfect example of when to use progressive enhancement.\n<\/p>\n
\n whether the feature’s API is available and gracefully degrade if unavailable.\n <\/p>\n
\n analytics to learn which browsers are most popular among your user base.\n <\/p>\n<\/div>\n
<\/p>\nTest with Search Console<\/h2>\n
\n Search Console<\/a> to
\n fetch individual URLs from your site<\/a>
\n and see how Google Search views them using the “Crawl > Fetch as Google” feature. Search
\n Console will process your JavaScript and render the page when that option is selected; otherwise
\n only the raw HTML response is shown.\n<\/p>\n
\n detecting the presence of Structured Data, Rich Cards, Sitelinks and Accelerated Mobile Pages.\n<\/p>\n
\n It can be an effective way to ensure Google Search is aware of all your site’s pages.\n <\/p>\n<\/div>\n
<\/p>\nAnnotate with Schema.org structured data<\/h2>\n
\n flexible vocabulary for summarizing the most important parts of your page as machine-processable
\n data. This can be as general as simply saying that a page is a NewsArticle<\/code>, or as
\n specific as detailing the location, band name, venue and ticket vendor for a touring band, or
\n summarizing the ingredients and steps for a recipe.\n<\/p>\n
\n recommended where it’s sensible. Google extracts it after the page is rendered.\n<\/p>\nNewsArticle<\/code>, Recipe<\/code>, and
\n Product<\/code> to name a few. You can also explore all the
\n supported data types here<\/a>.\n<\/p>\n
\n Structured Data Testing Tool<\/a>.\n <\/p>\n
\n Recipe<\/code> for a T-Shirt you’re selling—use Product<\/code> instead.\n <\/p>\n<\/div>\n
<\/p>\nAnnotate with Open Graph and Twitter Cards<\/h2>\n
\n Open Graph protocol and Twitter rich cards as well.\n<\/p>\n
\n corresponding social networks.\n<\/p>\n
\n included in your progressive web application as well for optimal virality.\n<\/p>\n
\n Facebook Object Debugger Tool<\/a>.\n <\/p>\n
\n Twitter’s metadata format<\/a>.\n <\/p>\n<\/div>\n
<\/p>\nTest with Multiple Browsers<\/h2>\n
\n across all browsers. While the experience might adapt for different screen sizes we all expect a
\n mobile site to work the same on similarly sized devices whether it’s an iPhone or an Android
\n mobile phone.\n<\/p>\n
\n this variety and competition is part of what makes the web such an innovative platform.
\n Thankfully, web standards have never been more mature than they are now and modern tools enable
\n developers to build rich, cross browser compatible websites with confidence.\n<\/p>\n
\n BrowserStack.com<\/a>,
\n Browserling.com<\/a> oder
\n BrowserShots.org<\/a> to ensure your PWA is
\n cross browser
\n compatible.\n <\/p>\n<\/div>\n
<\/p>\nMeasure Page Load Performance<\/h2>\n
\n Optimizing for page speed is already a well known focus in web development but sometimes when
\n developing a new version of a site the necessary optimizations are not considered a high priority.\n<\/p>\n
\n load speed and optimizing before launching the site for the best results.\n<\/p>\n
\n Page Speed Insights<\/a> and
\n Web Page Test<\/a>
\n to measure the page load performance of your site. While Googlebot has a bit more patience in
\n rendering,
\n research has shown<\/a>
\n that 40% of consumers will leave a page that takes longer than three seconds to load.\n <\/p>\n
\n critical rendering path here<\/a>.\n <\/p>\n<\/div>\n
\n migrating to a new progressive web application then it’s important to not regress in your
\n optimizations.\n <\/p>\n<\/div>\n
<\/p>\n
\n your Progressive Web Applications with indexability in mind.\n<\/p>\n
\n Progressive Web App indexability samples<\/a>
\n that demonstrate server-side, client-side, and hybrid rendering. As always, if you have any
\n questions, please reach out on our
\n Webmaster Forums<\/a>.\n<\/p>\n