When creating a modern web page, there are three major components:
- HTML –
Hypertext Markup Language serves as the backbone, or organizer of content, on a site. It is the structure of the website (e.g. headings, paragraphs, list elements, etc.) and defining static content.
- CSS –
Cascading Style Sheets are the design, glitz, glam, and style added to a website. It makes up the presentation layer of the page.
A common use of AJAX is to update the content or layout of a webpage without initiating a full page refresh. Normally, when a page loads, all the assets on the page must be requested and fetched from the server and then rendered on the page. However, with AJAX, only the assets that differ between pages need to be loaded, which improves the user experience as they do not have to refresh the entire page.
One can think of AJAX as mini server calls. A good example of AJAX in action is Google Maps. The page updates without a full page reload (i.e., mini server calls are being used to load content as the user navigates).
As an SEO professional, you need to understand what the DOM is, because it’s what Google is using to analyze and understand webpages.
The DOM is what you see when you “Inspect Element” in a browser. Simply put, you can think of the DOM as the steps the browser takes after receiving the HTML document to render the page.
The DOM is what forms from this parsing of information and resources. One can think of it as a structured, organized version of the webpage’s code.
Headless browsing is simply the action of fetching webpages without the user interface. It is important to understand because Google,and now Baidu, leverage headless browsing to gain a better understanding of the user’s experience and the content of webpages.
- Crawlability: Bots’ ability to crawl your site.
- Obtainability: Bots’ ability to access information and parse your content.
- Perceived site latency: AKA the Critical Rendering Path.
Are bots able to find URLs and understand your site’s architecture? There are two important elements here:
The easiest way to solve this problem is through providing search engines access to the resources they need to understand your user experience.
_!!! Important note:_Work with your development team to determine which files should and should not be accessible to search engines.
Internal linking is a strong signal to search engines regarding the site’s architecture and importance of pages. In fact, internal links are so strong that they can (in certain situations) override “SEO hints” such as canonical tags.
- Not recommended:
- The Lone Hash (#) –
The lone pound symbol is not crawlable. It is used to identify anchor link (aka jump links). These are the links that allow one to jump to a piece of content on a page. Anything after the lone hash portion of the URL is never sent to the server and will cause the page to automatically scroll to the first element with a matching ID (or the first
element with a name of the following information).
avoiding the use of “#“ in URLs.
- Hashbang (#!) (and
Hashbang URLs were a hack to support crawlers (Google wants to avoid now and only Bing supports). Many a moon ago, Google and Bing developed a complicated AJAX solution, whereby a pretty (#!) URL with the UX co-existed with an equivalent escaped_fragment HTML-based experience for bots. Google has since backtracked on this recommendation, preferring to receive the exact user experience. In escaped fragments, there are two experiences here:
- Original Experience (aka Pretty URL):
This URL must either have a #! (hashbang) within the URL to indicate that there is an escaped fragment or a meta element indicating that an escaped fragment exists (
meta name=”fragment” content=”!”
- Escaped Fragment (aka Ugly URL, HTML snapshot):
This URL replace the hashbang (#!) with “_escaped_fragment_” and serves the HTML snapshot. It is called the ugly URL because it’s long and looks like (and for all intents and purposes is) a hack.
- Original Experience (aka Pretty URL):
- The Lone Hash (#) –
- pushState History API –
PushState is navigation-based and part of the History API (think: your web browsing history). Essentially, pushState updates the URL in the address bar and only what needs to change on the page is updated. It allows JS sites to leverage “clean” URLs. PushState is currently
supported by Google
, when supporting browser navigation for client-side or hybrid rendering.
- A good use of pushState is for infinite scroll (i.e., as the user hits new parts of the page the URL will update). Ideally, if the user refreshes the page, the experience will land them in the exact same spot. However, they do not need to refresh the page, as the content updates as they scroll down, while the URL is updated in the address bar.
- Example: A good example of a search engine-friendly infinite scroll implementation, created by Google’s John Mueller (go figure), can be found
. He technically leverages the replaceState(), which doesn’t include the same back button functionality as pushState.
- Read more:
Mozilla PushState History API Documents
- pushState History API –
- If the user must interact for something to fire, search engines probably aren’t seeing it.
- Google is a lazy user. It doesn’t click, it doesn’t scroll, and it doesn’t log in. If the full UX demands action from the user, special precautions should be taken to ensure that bots are receiving an equivalent experience.
John Mueller mentioned
that there is no specific timeout value; however, sites should aim to load within five seconds.
Screaming Frog tests
show a correlation to five seconds to render content.
- *The load event plus five seconds is what Google’s PageSpeed Insights, Mobile Friendliness Tool, and Fetch as Google use; check out
Max Prin’s test timer
All of these studies are amazing and help SEOs understand when to be concerned and take a proactive role. However, before you determine that sitting back is the right solution for your site, I recommend being actively cautious by experimenting with small section Think: Jim Collin’s “bullets, then cannonballs” philosophy from his bookGreat by Choice:
“A bullet is an empirical test aimed at learning what works and meets three criteria: a bullet must be low-cost, low-risk, and low-distraction… 10Xers use bullets to empirically validate what will actually work. Based on that empirical validation, they then concentrate their resources to fire a cannonball, enabling large returns from concentrated bets.”
Consider testing and reviewing through the following:
- Confirm that your content is appearing within the DOM.
- Test a subset of pages to see if Google can index content.
- Manually check quotes from your content.
Fetch with Google and see if content appears.
- Note: If you aren’t verified in GSC, try
Technicalseo.com’s Fetch and Render As Any Bot Tool
After you’ve tested all this, what if something’s not working and search engines and bots are struggling to index and obtain your content? Perhaps you’re concerned about alternative search engines (DuckDuckGo, Facebook, LinkedIn, etc.), or maybe you’re leveraging meta information that needs to be parsed by other bots, such as Twitter summary cards or Facebook Open Graph tags. If any of this is identified in testing or presents itself as a concern, an HTML snapshot may be the only decision.
HTML snapshots are a fully rendered page (as one might see in the DOM) that can be returned to search engine bots (think: a static HTML version of the DOM).
Google introduced HTML snapshots 2009,deprecated (but still supported) them in 2015, and awkwardly mentioned them asan element to “avoid”in late 2016. HTML snapshots are a contentious topic with Google. However, they’re important to understand, because in certain situations they’re necessary.
When considering HTML snapshots, you must consider that Google has deprecated this AJAX recommendation. Although Google technically still supports it, Google recommends avoiding it. Yes, Google changed its mind and now want to receive the same experience as the user. This direction makes sense, as it allows the bot to receive an experience more true to the user experience.
A second consideration factor relates to the risk of cloaking. If the HTML snapshots are found to not represent the experience on the page, it’s considered a cloaking risk. Straight from the source:
“The HTML snapshot must contain the same content as the end user would see in a browser. If this is not the case, it may be considered cloaking.”
Despite the considerations, HTML snapshots have powerful advantages:
- Knowledge that search engines and crawlers will be able to understand the experience.
- Other search engines and crawlers (think: Bing, Facebook) will be able to understand the experience.
When browsers receive an HTML document and create the DOM (although there is some level of pre-scanning), most resources are loaded as they appear within the HTML document. This means that if you have a huge file toward the top of your HTML document, a browser will load that immense file first.
The concept of Google’s critical rendering path is to load what the user needs as soon as possible, which can be translated to → “get everything above-the-fold in front of the user, ASAP.”
_!!! Important note:_It’s important to understand that scripts must be arranged in order of precedence. Scripts that are used to load the above-the-fold content must be prioritized and should not be deferred. Also, any script that references another file can only be used after the referenced file has loaded. Make sure to work closely with your development team to confirm that there are no interruptions to the user’s experience.
Read more:Google Developer’s Speed Documentation
Thanks:Thank you Max Prin (@maxxeight) for reviewing this content piece and sharing your knowledge, insight, and wisdom. It wouldn’t be the same without you.