JavaScript Rendering & SEO
Search engines treat JavaScript content on a website differently from typical HTML content and will render it separately. As the use of JavaScript on the web increases due to the number of features it makes possible, it is important to understand how search engines view this content and optimize for this. Check out our “Hamburger Analogy” an introduction to client-side vs. server-side JavaScript rendering.
Our SEO Office Hours notes and video clips compiled here cover JavaScript-related SEO best practices from Google, along with notes on the latest advancements to their rendering engine.
Injecting Markup Using JavaScript Isn’t Recommended
Avoid injecting markup on a page using JavaScript as this makes it more difficult to debug and test that the schema is working correctly. Include markup in the source code where possible.
Malware Can be Served via Your Site if You Serve External Content via JavaScript
If you serve content from 3rd parties via JavaScript then be aware that if the websites hosting the content get hacked or edit their JS code to serve malware, then Google will flag your site as serving malware.
Combine Separate CSS, JS & Tracking URLs to Increase Googlebot Requests to Your Server
To improve site speed and allow Googlebot to send requests to your server more frequently, reduce the number of external URLs that need to be loaded. For example, combine CSS files into one URL, or as few URLs as possible.
Fetch & Render Tool in GSC Doesn’t Reflect Real Rendering
Getting ‘temporarily unreachable’ messages in the Fetch & Render tool doesn’t reflect how Google is rendering content for its index. Google’s rendering service has a longer cutoff time and uses caching.
Google Won’t Fetch Third-party Scripts that Aren’t Deemed to be Useful
Google is getting better at recognising third-party scripts that aren’t useful for it to fetch and render, so will avoid fetching those where it can.
Using HTTP/2 Doesn’t Reduce Resource Cost for Google Rendering JavaScript
Google will still have to parse, compile and execute JavaScript after the initial transfer which are the three most expensive elements of rendering, so serving JavaScript via HTTP/2 doesn’t reduce cost.
Don’t Serve Critical JavaScript in the Head as This Can Block Rendering
Any JavaScript that is deemed to be critical will most likely be of a significant file size, so shouldn’t be served in the head as this can delay rendering, meaning the user will have to wait longer before seeing any content. Serve priority content to users as quickly as possible without JavaScript if possible.
Website Owners Don’t Need to Specify What Google Should & Shouldn’t Render
Website owners don’t need to implement anything on their sites that would tell Google what is unnecessary to render, as it should be Google’s job to figure this out. Being selective and not rendering particular elements can also cause problems for a website.
Scroll Events Shouldn’t be Used in Isolation to Execute Lazy-loading
Scroll events aren’t always the best solution because they are expensive, users on desktop may resize their window to get more content which wouldn’t trigger a scroll event, and Google doesn’t scroll. Test lazy-loading is working by using Fetch & Render and Intersection Observer.
Google Can Process JavaScript Redirects as Long as it Can Crawl Them
JavaScript redirects don’t usually cause any problems for Google as long as it can crawl them, and they are treated as regular redirects. Make sure these redirects aren’t disallowed, however, as Google won’t be able to process them.