But it’s also a good way to kill a website’s SEO if implemented incorrectly.
Here’s a simple truth:
Even the best things in the world need a way to be found.
- Your website pages
- Important content blocks on your website pages
After redesigning our website in React, our traffic has dropped drastically. What happened?’.
This is just one of the many questions I’ve heard from my potential clients or seen on forums. You can replace ‘React’ with any other JS framework, it doesn’t matter. Any of them can hurt a website if implemented without any SEO considerations.
Example 1: Website Navigation is Not Crawlable
What’s wrong here:
The links in the navigation are added not according to the web standards. As a result, Google can’t see or follow them.
Why it’s wrong:
- It makes it harder for Google to discover the internal pages
- The authority within the website is not properly distributed
- There’s no clear indication of relationships between the pages within the website
As a result, a website with links that Googlebot can’t follow will not be able to utilize the power of internal linking.
Example 2: Image Search Has Decreased After Improper Lazy Load Implementation
What’s wrong here:
While lazy loading is a great way to decrease page load time, it can also be dangerous if implemented incorrectly.
In this example, lazy loading prevented Google from seeing the images on the page.
Why it’s wrong:
- The content ‘hidden’ under lazy loading might not be discovered by Google (when implemented incorrectly)
- If the content is not discovered by Google, the content is not ranked
As a result, image search traffic can suffer a lot. It’s especially critical for any business that heavily relies on visual search.
Example 3: The Website Was Switched to React with No Consideration of SEO
What’s wrong here:
This is my ‘favourite’ example from a website I audited a whale ago. The owner came to me after all traffic just tanked. It’s like they unintentionally were trying to kill their website:
- The URLs were not crawlable
- The images were not crawlable
- The title tags were the same across all website pages
- There was no text content on the internal pages
Why it’s wrong:
- If Google doesn’t see any content on the page, it won’t rank this page
- If multiple pages look the same to Googlebot, it can choose just one of them and canonicalize the rest to it.
In this example, the website pages looked exactly the same to Google, so it deduplicated them and used the homepage as a canonical version.
When it comes to how Google treats your content, there are a few main things you should know.
Google doesn’t interact with your content
It means Googlebot can’t click the buttons on your pages, expand/collapse the content, etc.
Googlebot can see only the content which is available in rendered HTML without any additional interaction.
For example, if you have an expandable text section, and its text is available in the source code or rendered HTML, Google will index it.
On the contrary, if you have a section where the content is not initially available in the page source code or DOM and loads only after a user interacts with it (e.g. clicks a button), Google won’t see this content.
Google doesn’t scroll
Googlebot does not behave like a usual user on a website, it doesn’t scroll through the pages. So if your content is ‘hidden’ behind an endless amount of scrolls, Google won’t see it.
Google doesn’t see the content which is rendered only in a browser vs on a server
That’s why client-side rendering is a bad idea if you want Google to index and rank your website (and you do want it if you need traffic and sales).
Add links according to the web standards
While ‘web standards’ can sound intimidating, in reality, it just means you should link to internal pages using the HREF attribute:
<a href=”your-link-goes-here”>Your relevant anchor text</a>
This way Google can easily find the links and follow them (unless you add a nofollow attribute to them but it’s a different story).
Don’t use the following techniques to add internal links on your website:
- <a onclick=“goto(‘https://store.com/page-url’)”>
By the way, the last option can still be successfully used on a page if you want to bring people to a specific part of this page. But Google will not index all individual variations of your URL with “#” added to it.
Add images according to the web standards
Exactly like with internal links, image usage should also follow web standards so that Googlebot can easily discover and index images.
To be discovered, an image should be linked from the ‘src’ HTML tag:
<img src=”image-link-here.png” />
<img data-src=”image-link-here.png” class=”inline lazyloaded” src=”placeholder-imge.gif”></div>
<img data-src> stores additional info about the image
It helps with page speed optimization and works well if implemented correctly.
If you want Google to pick up your real image instead of the placeholder, you should swap the placeholder image to the target image, so that <img src> shows the path to the target image.
Use server-side rendering
If you want Google to read and rank your content, you should make sure this content is available on the server, not just in a user’s browser.
Make sure that rendered HTML has all the main information you want Google to read
You need to make sure that rendered HTML shows the right information such as:
- Copy on the page
- Canonical tag
- Title & meta description
- Meta robots tag
- Structured data
- Any other important tags
Gone are the days when you’d just need to look at the source code of a page and check if it includes the right content.
Once you do it, you’ll see how a page would look without any JS.
That’s why you need to test the rendered HTML with the tools I’ll show you in the next step.
Step 2: Check if Googlebot is served the right content and tags
Google Mobile-friendly Test Tool
Google Mobile-friendly Test Tool is one of the best and reliable tools when it comes to checking mobile rendered HTML because you get information right from Google.
What you need to do:
- Load the Mobile-friendly tool
- Check your URL
- Look at the info in the HTML tab:
That’s where the tech SEO side comes in as you’ll have to check the code to make sure it has the right information.
Note: you can use the Rich Results Test tool to do these checks too:
URL Inspection Tool in Google Search Console
The URL Inspection tool also gives you access to the raw HTML of your page that Googlebot uses for evaluating your page content:
The Mobile-friendly Test Tool vs The URL Inspection Tool
Ok, so what’s the difference between these tools and which one is more preferred?
The short answer is: there’s no difference in the output since the Mobile-Friendly Test and the URL inspection tool use the same core technology.
There’s some difference in other aspects though:
- To use the URL Inspection Tool, you need to have access to the Google Search Console of the website you’re checking. So if you don’t have such access, you’d need to use the Mobile-Friendly Test (or Rich Results Test).
The Mobile-Friendly Test and Rich Results Test give you the output for your current live page version only.
Other Debugging Tools
Note: make sure you check mobile rendered HTML vs desktop. To do this, you need to first load a mobile view in the Chrome inspection tool and then use the View Rendered Source extension:
I think this is the most user-friendly JS debugging tool as you don’t even need to check the code. It checks the main elements in the page source code for you and compares them to the same elements in the rendered HTML (again, make sure to check the mobile version):
You can also use the SEO Pro extension to see the Title tag and other important tags that are found in rendered HTML, not source code:
The post was originally published on the Search Engine Journal.