JavaScript SEO – Comprehensive Guide For SEOs & Developers

Updated: May 5, 2024.

Here is your ultimate guide to JavaScript SEO. It covers all the essential elements and answers the most critical JavaScript SEO FAQs.  

I recently had the privilege of interviewing Martin Splitt from Google to discuss JavaScript SEO. I asked him lots of JavaScript SEO questions and got very in-depth responses. I learned so much. 

Moreover, with over 12 years of experience as a technical SEO, I’ve encountered and overcome numerous challenges with JavaScript websites.

In this guide, I am sharing my experience with JavaScript SEO, the invaluable insights I gained from my interview with Martin Splitt, and the knowledge from the Google documentation on JavaScript and SEO.  

Ready to master JavaScript SEO? Let’s get started!

What is JavaScript SEO? TL;DR

JavaScript SEO is the practice of optimizing websites that rely on JavaScript to function properly for search engines. 

The goal is to ensure that search engine bots can crawl, render, and index the content and links generated by JavaScript. 

This is important because search engines rank pages based on the content they can perceive. If critical content is not visible to search engines due to JavaScript issues, it can negatively impact the site’s visibility and rankings.

JavaScript SEO basic diagnostics

To be able to diagnose JavaScript SEO issues, you need to know how to check if a website relies on JavaScript (and how much), if Google can see the JavaScript-added content, and if the JavaScript content is indexed.

Below are the three most important diagnostics for JavaScript SEO.

How to check a website’s reliance on JavaScript

The easiest and fastest way to check how much a site/page relies on JavaScript is to disable it in the browser and check whether the main content and links are visible without it.

All you need to do is:

• Install and download Chrome Web Developer if you haven’t already done so.
• Open the page you want to investigate.
• Click the Web Developer icon, choose Disable, and then “Disable JavaScript”.

If you see an empty page or if huge pieces of content are missing, the page relies on JavaScript to generate it.

This method works if you want to check a few pages manually. For bulk checking, I recommend using a dedicated crawler.

How to check JavaScript reliance in bulk

To analyze JavaScript reliance on many pages in bulk, use your favorite crawler without JavaScript rendering.

I would use one of the following:

• JetOctopus (make sure to tick off JavaScript rendering when configuring the crawl)

• Screaming Frog SEO Spider (crawl with Text Only)

• Sitebulb (choose HTML Crawler)

This way, you will have the data for all pages or a meaningful sample. If the crawl data is missing important content or links, it means the site relies on JavaScript to generate it.

In that case, your next logical move is to check how Googlebot sees the page and if it can see all the content and links (next step below).

And for bulk analysis of a JavaScript-based website, you will want to do another crawl with JavaScript rendering.

In most cases, it is a good idea to always crawl with JavaScript rendering because most crawlers will allow you to compare the source and rendered HTML. However, you must always be mindful of possible server overload and what percentage of the site you should/need to crawl. Crawling 100% of URLs is not always necessary (especially with a desktop-based crawler and a huge site).

Finally, with bulk JS rendering, remember that how your crawler renders JavaScript does not necessarily mean it is how Googlebot does that (more about that in the further section with answers from Martin Splitt).

Related article: How To Disable JavaScript In Chrome

How to check how Googlebot sees the page

There are two ways to see the rendered HTML (what Googlebot actually sees). Do not confuse this with the rendered HTML your crawler shows you!

Use the URL Inspection tool in Google Search Console

The URL Inspection tool in Google Search Console allows you to look at the page through Googlebot’s eyes.

Inspect the URL, then click ‘VIEW CRAWLED PAGE’ and check ‘HTML’ and ‘SCREENSHOT’ to see the version of the page that Googlebot sees.

If important content and links are missing, you have a problem.

This method, obviously, only works if you have access to the site in GSC, which you may not always have (especially with prospects).

Use The Rich Results Test

The main purpose of the Rich Results Test is to analyze structured data. However, you don’t always have access to the site in Google Search Console, so this is when the Rich Results Test becomes super useful.

Test the URL you want to analyze from Googlebot’s perspective and then click ‘VIEW TESTED PAGE’.

Similar to what you had in GSC, you can see ‘HTML’ and ‘SCREENSHOT’ tabs that show you exactly how Googlebot sees that page!

In the past, you could use the Mobile-Friendly Test for that, but this tool has been retired, so the Rich Results Test is your tool now.

How to check if JavaScript content is indexed 

To check if JavaScript-generated content is indexed by Google, you can use the site: Google search operator followed by the URL of the page you want to check. 

If the JavaScript-generated content appears in the search results, it means Google has indexed it successfully. 

If you see something like below, then it means this piece of text is not indexed by Google.

In the example above, this is the sentence from my JS-added bio. It looks like Googlebot is not indexing this piece!

Remember that this method may not be reliable if a given page (whose piece of text you are searching for in quotes on Google) hasn’t been indexed yet. In that case, it does not have to mean that Google cannot see the JS-based content. Use the URL Inspection tool to confirm that.

Another method to check if JavaScript-added content is indexed is—again—to use the URL Inspection Tool in Google Search Console.

As explained above, this tool shows you how Google renders and indexes a specific page (tabs ‘HTML’ and ‘SCREENSHOT’).  

Note that ‘SCREENSHOT’ is available only in the live test.

The ‘SCREENSHOT’ only acts as a preview, not showing the entire page.

To ensure that the important content or links are visible to Google, you must compare the source code with the rendered HTML side by side.

If the JavaScript-generated content is visible in the rendered HTML, it confirms that Google can properly process and index that content.

JavaScript SEO essentials

In this section, I discuss the most important topics related to JavaScript SEO. The awareness of these topics is critical if you want to understand JavaScript SEO and be a successful technical SEO. 

How does Google process JavaScript?

Google’s processing of JavaScript web apps involves three key stages: crawling, rendering, and indexing.

Googlebot adds pages to both the crawling and rendering queues, and the timing of each stage varies. During the crawling phase, Googlebot checks the robots.txt file to ensure the URL is allowed before making an HTTP request. If the URL is disallowed, Googlebot skips it entirely.

For permitted URLs, Googlebot parses the HTML response for links and adds them to the crawl queue. JavaScript-injected links are acceptable if they adhere to best practices.

The rendering phase involves executing JavaScript on a page to generate dynamic content, which is then used for indexing. Server-side or pre-rendering can improve website performance and accessibility for users and crawlers alike.

PRO TIP: The important thing to know is that crawling does not equal rendering, rendering does not equal indexing, and indexing does not equal ranking. Make sure to check Google’s documentation explaning the three stages of Google Search in detail.

Does Googlebot behave like real website users? 

No, Googlebot does not behave exactly like human users. While it can execute JavaScript and render web pages, it does not interact with the page as a user would. 

Googlebot does not click buttons, fill out forms, or scroll through content. Therefore, if your content is loaded based on user interactions, Googlebot may be unable to discover and index it. 

PRO TIP: It’s crucial to ensure that all critical content and links are accessible without user interaction.

JavaScript links and SEO

When it comes to links and SEO, it’s essential to use standard HTML anchor tags with href attributes (<a href="https://seosly.com/blog/javascript-seo/...">). These links are easily discoverable and followed by search engine crawlers. 

JavaScript links can work for SEO but are not the most reliable or recommended option. If the links are generated using JavaScript, search engines may have difficulty discovering and following them. 

However, if the JavaScript-generated links are present in the rendered HTML, search engines can still find and follow them. JavaScript links can be used in certain situations, such as when creating dynamic navigation menus or handling user interactions. 

Most crawlers (like the ones mentioned above) will let you analyze JavaScript links in bulk so that you can draw the best conclusions.

BEST PRACTICE: Whenever possible, it’s best to use standard HTML links for optimal SEO performance.

JavaScript redirects and SEO 

JavaScript redirects can be problematic for SEO because Google needs to render the page and execute the JavaScript to see the redirect.

This delays the crawling and indexing process. In fact, Google recommends using JavaScript redirects only as a last resort.

The most efficient redirects for SEO are server-side redirects, such as 301 (permanent) and 302 (temporary) HTTP redirects. Googlebot processes these redirects in the crawling stage before rendering them, so they are faster and more reliable.

However, if you must use JavaScript redirects, Google can still handle them. When Googlebot renders the page and executes the JavaScript, it will see and follow the redirect. The process just takes longer compared to server-side redirects.

Most website crawlers will let you check if there are JavaScript redirects. Below you can see the report from Screaming Frog SEO Spider.

An example of a JavaScript redirect is:

codewindow.location.href="https://www.example.com/new-page";

JavaScript SEO common issues

Unfortunately, JavaScript very often leads to various negative SEO consequences. In this section, I discuss the most common ones and offer some best practices. 

Google does not scroll or click

One of the most important things to understand about Googlebot is that it does not behave like a human user.

It does not scroll through pages or click on buttons and links. This means that if you have content that loads only after a user scrolls down or clicks a button, Googlebot will likely not see that content.

For example, if you have a “Load More” button at the bottom of a page that loads more products when clicked, Googlebot will not click that button. As a result, it will not see or index the products that are loaded only after the button is clicked.

TIP: To ensure Googlebot can access all your content, make sure it’s loaded in the initial HTML or through JavaScript, which doesn’t require user interaction.

Similar to the issue with scrolling and clicking, if your pagination relies on JavaScript and user interaction, Googlebot may be unable to access pages beyond the first page.

For instance, if your category pages use a “Load More” button to reveal more products without proper <a> tags, Googlebot won’t be able to discover and index the products on subsequent pages.

The best solution is to use traditional HTML links for pagination, ensuring each page has a unique, accessible URL.

JavaScript-based internal links

JavaScript-based links can also cause issues for SEO. If your site generates links using JavaScript, Googlebot might be unable to follow them.

For example:

<a href="https://seosly.com/blog/javascript-seo/javascript:void(0)" onclick="navigate("https://seosly.com/page")">Link</a>

In this case, the link doesn’t have a proper URL in the href attribute, making it difficult for Googlebot to follow.

Instead, use traditional <a> tags with valid URLs:

<a href="https://seosly.com/page">Link</a>

If your website’s navigation menu relies on JavaScript to function, Googlebot might have trouble discovering and following the links.

This can result in important pages not being crawled and indexed and compromise the power of internal linking.

To avoid this, ensure your menu links are present in the initial HTML as standard <a> tags. If you must use JavaScript for your menu, make sure the links are still accessible and functional without JavaScript.

According to Barry Adams, JavaScript-based navigation menus can pose a challenge for SEO, particularly when they use fold-out or hamburger-style menus to display additional links. While this design pattern is common, especially on mobile, it can cause issues if the menu links are not properly loaded into the HTML source code.

PRO TIP: To avoid this issue, it’s crucial to ensure that all navigation links are present in the HTML source code and do not require any client-side script interaction to be accessible to search engines.

Blocking important resources in robots.txt

Sometimes developers accidentally block important JavaScript or CSS files in the robots.txt file. If Googlebot can’t access these files, it may not be able to render and index your pages properly.

When Googlebot crawls a website, it first checks the robots.txt file to determine which pages and resources it is allowed to access. If the robots.txt file blocks critical JavaScript or CSS files, Googlebot won’t be able to render the page as intended, leading to incomplete or incorrect indexing.

Here’s an example of a robots.txt file that blocks important resources:

User-agent: *
Disallow: /js/
Disallow: /css/

In this example, the robots.txt file blocks access to all files within the /js/ and /css/ directories. If these directories contain files essential for rendering the website correctly, Googlebot won’t be able to process and index the content properly.

All website crawlers allow you to check if your robots.txt blocks important resources. Here is JetOctopus’s report.

To avoid this issue, ensure that your robots.txt file does not block critical JavaScript, CSS, or other resources required for proper rendering.

Using only JavaScript redirects

While JavaScript redirects can work, they’re not as efficient or reliable as server-side redirects.

With JavaScript redirects, Googlebot must render the page and execute the JavaScript to discover the redirect, which can delay the process.

PRO TIP: Whenever possible, use server-side 301 redirects instead. If you must use JavaScript redirects, ensure they’re implemented correctly and can be followed by Googlebot.

Relying on URLs with Hashes

URLs containing hashes (#) are often used in single-page applications (SPAs) to load different content without refreshing the page. 

However, Googlebot treats URLs with hashes as a single URL, meaning it won’t index the content accessed through hash changes as separate pages.

To make your content indexable, use the History API to update the URL and serve unique content for each URL, ensuring each page has a distinct, crawlable URL without hashes.

Soft 404 and JavaScript

When it comes to 404 errors and JavaScript, a common issue known as soft 404 errors can arise.

This happens when pages that should return a 404 status code (indicating that the page doesn’t exist) instead return a 200 status code (suggesting that the page is valid). 

As a result, these pages may be indexed by search engines, leading to index bloat and potentially affecting the website’s performance in search results. In some cases, JavaScript can contribute to this problem by dynamically changing the site’s content.

To mitigate soft 404 errors, it is essential to ensure that proper 404 error codes are returned to Googlebot as expected. This can be particularly challenging if your website uses dynamic rendering. 

• To detect soft 404 errors, you can crawl your website using specialized software and look for pages that return 200 HTTP status codes but do not provide any unique value, such as pages with duplicate titles indicating that the content doesn’t exist. 
• If you suspect JavaScript is causing the issue, perform a JavaScript-aware crawl rather than a regular one. 
• Additionally, you can use Google Search Console to identify URLs that return 200 HTTP status codes instead of the appropriate 404 errors, as they are usually labeled as “Soft 404” in the Page Indexing report.

Once identified, you can resolve the issue by updating the pages to return proper 404 status codes.

JavaScript dynamic content (dynamic rendering) and SEO

Dynamic rendering refers to serving different content to users and search engine bots. While it can help complex JavaScript websites get indexed, it comes with challenges.

Dynamic rendering requires maintaining separate versions of your website for users and bots, which can be resource-intensive. It also introduces the risk of cloaking if not implemented correctly.

BEST PRACTICE: Google recommends using dynamic rendering only as a temporary solution while working towards server-side rendering or pre-rendering, which provides better performance and a more consistent experience for users and search engines.

JavaScript and website speed

JavaScript can significantly impact website speed. Large, unoptimized JavaScript files can slow down page loading times, affecting user experience and search engine rankings.

To minimize the impact of JavaScript on site speed:

• Minify and compress JavaScript files
• Remove unused JavaScript code
• Defer or asynchronously load non-critical JavaScript
• Use efficient, well-structured code
• Leverage browser caching for JavaScript files

Tools like Google PageSpeed Insights can help identify JavaScript-related performance issues and provide optimization suggestions.

JavaScript SEO and SGE (Search Generative Experience)

According to the study run by Onely, it appears that SGE (Search Generative Experience) primarily uses content from the HTML body to generate its responses, rather than heavily relying on rendered content from JavaScript execution.

The key findings that support this conclusion are:

• Around 88% of the analyzed text fragments in SGE responses were found in the HTML body, indicating that SGE mainly fetches content directly from the HTML source.
• The remaining 12% (the “Not found” segment) consisted of content from various sources, with JavaScript-dependent content accounting for only about 3.5% of the total.
• Other sources in the “Not found” segment included page descriptions (7.5%), schema markups (less than 1%), and titles (less than 1%).

While SGE can handle some JavaScript-dependent content, most of its responses appear to be generated using content readily available in the HTML source code. This suggests that SGE does not heavily rely on rendering JavaScript to fetch content for its responses.

However, it’s important to note that the manual analysis of the “Not found” segment was conducted on a small sample, and the estimates may not accurately represent the true proportions.

BEST PRACTICE: To ensure your content is accessible to SGE, it is recommended that you include your main content directly in the HTML whenever possible. This will ensure that Google can crawl, render, and index your main content without issues, even if your website relies on JavaScript.

Make sure to read Google’s documentation on JavaScript SEO problems.

Martin Splitt from Google on JavaScript SEO

Here are all the JavaScript SEO questions I asked Martin Splitt and his answers. This is pure gold!

You can watch the entire interview below. Specific questions are added as video chapters. Below are written summaries of Martin’s answers.

What is the path that Googlebot follows when it visits a page? 

The path Googlebot follows when it visits a page is:

1. Googlebot gets a URL from a list of URLs to crawl.
2. It looks at the host domain and checks for a robots.txt file. If allowed, it makes an HTTP request to the URL.
3. Googlebot records the response it receives, including metadata like timing, headers, and IP address. This is passed to the next system.
4. The response is analyzed to see if it contains other URLs to crawl potentially. If so, those are passed to a dispatcher, which prioritizes them and adds them to the crawl queue.
5. The original response moves to the indexing system, where it is checked to see if it’s a successful 200 OK response or an error.
6. Assuming it’s a successful HTML response, the content gets converted to an HTML representation if needed.
7. The HTML is analyzed to determine language, creation/update dates, if it’s been seen before, and more.
8. The page is rendered in a headless Chrome browser to execute JavaScript and potentially generate additional content and information.

So, in summary, Googlebot queues the URL, fetches it, and passes the response for indexing, where it is analyzed, rendered, and has key information extracted, assuming it’s an eligible, non-error page. 

How does Google decide whether to index a specific page?

According to Martin Splitt from Google, the decision to index a specific page is based on several factors. Google has systems in place that analyze the content of a page to determine if it is useful, high-quality, and relevant to users.

If the content appears to be valuable and unique (i.e., not already indexed), Google is likely to include it in the index. However, if the page contains minimal content, such as a simple “hello” or “hello world” message, it may not be considered useful enough to warrant indexing.

Furthermore, if Google detects that the content is very similar or duplicated across multiple URLs, it may choose to index only one version and exclude the others. In such cases, Google will indicate that the page is duplicated and show the canonical URL selected for indexing.

Google also considers factors like the likelihood of a page appearing in search results based on historical data. If a page hasn’t appeared in search results for an extended period (e.g., years), Google might remove it from the index. However, if there’s still a chance that the page could be relevant for some queries, Google may keep it indexed.

It’s important to note that indexing does not guarantee ranking. Indexed pages are stored in Google’s database and can potentially appear in search results, but their actual visibility depends on various ranking factors.

TAKEAWAY: Google’s decision to index a page is based on its assessment of the content’s quality, uniqueness, and potential relevance to users. Pages may move in and out of the index over time based on these factors and the demand for the content.

Google Search Console has recently got specific robots.txt reports showing different variations of robots.txt and their status. Why were these reports added? Does it mean people often mess up robots.txt files?

The addition of specific robots.txt reports in Google Search Console, which show different variations of robots.txt (www, non-www, etc.) and their status, is likely due to the fact that people often make mistakes when implementing robots.txt files.

Martin suggests that it is not surprising that people fall into these “surprises” or make errors with robots.txt files, as they have seen similar issues with other aspects of websites, not just robots.txt.

It is common for websites to host different versions of their robots.txt files at different locations, such as subdomains that are controlled by different teams. This can lead to issues when one team makes changes to their robots.txt file, which might inadvertently affect other parts of the website.

By providing these detailed reports in Google Search Console, website owners can easily check and identify potential problems with their robots.txt files across different variations of their domain. This allows them to spot any inconsistencies or errors that may be causing issues with the indexing of their website.

Although Martin is not entirely certain about the specific user experience (UX) reasons behind adding these reports, they believe it makes sense to include them, given the likelihood of people making mistakes with robots.txt files and the potential impact on website indexing.

If in the GSC Indexing report under “Source,” there is “Google Systems,” does it mean that it is Google’s fault that specific pages weren’t indexed or crawled? 

If the Google Search Console (GSC) Indexing report shows “Google Systems” under the “Source” column, it does not necessarily mean that it is Google’s fault that specific pages weren’t indexed or crawled. As Martin explains, it simply means that Google’s systems found the URL information somewhere, and it is not exactly their fault.

When a URL appears as “Discovered—Currently not indexed” or “Crawled—Currently not indexed,” Google will eventually determine whether the page is worth its time. If it is not deemed valuable, Google’s crawling system will likely move on and focus elsewhere. Website owners shouldn’t worry too much about these URLs in such cases.

Furthermore, if the source is listed as “Google Systems,” it doesn’t imply that Google has something broken or unusual. It indicates that they discovered the URL internally through their systems rather than from sources like the website’s sitemap.

Martin suggests that this is not necessarily an issue that requires fixing unless it causes demonstrable problems for the website owner. Simply having URLs listed under “Google Systems” as the source does not automatically indicate a fault on Google’s part or a problem that needs immediate attention.

Should website owners (especially large e-commerce websites) be worried about the recent spam attack, in which GSC websites saw many 404 pages ending with /1000?

According to Martin, website owners, even those with large e-commerce websites, should not be overly concerned about the recent spam attack where Google Search Console (GSC) shows many 404 pages ending with /1000. 

This is because 404 errors are quickly removed from the processing pipeline, so they don’t cause significant problems.

However, if a website experiences a decline in crawl speed due to these spam URLs, it might be worth investigating and considering using robots.txt rules to avoid such issues. That being said, Martin hasn’t heard of any websites encountering serious problems due to these types of URLs.

He explains that hypothetically, if a million pages are linked to a URL that no longer exists or has never existed on a website, it is something that happens on the web, and Google needs to address it on a web scale. Therefore, it shouldn’t cause substantial problems for individual websites.

Can a small website (10K URLs) run into crawl budget issues if its canonicals and URLs with parameters are messed up?

Martin suggests that this shouldn’t be a significant issue. He states that if many non-canonical URLs are being crawled on a small website, the crawling will eventually slow down or die out quickly.

Google’s systems can predict which URL patterns have more value based on which ones are selected as canonicals.

In such cases, Google should adjust its crawling accordingly. Martin believes this situation is unlikely to cause a crawling issue unless it’s a new website with a million pages that must be updated frequently.

TAKEAWAY:  small websites with canonical and parameterized URL issues should not be overwhelmed by the additional crawling, as Google’s systems are designed to handle such situations efficiently.

What is the time difference between Googlebot crawling and rendering a page?

Martin explains that for most pages in search, the rendering occurs within minutes of crawling. Sometimes, it might take a few hours, and very rarely, it could be longer than that. 

If the rendering takes longer, it usually indicates that Google is not highly interested in the content, and the page may be less likely to be selected for indexing.

What will Googlebot index if the content on the page changes every second? 

Martin acknowledges that it is an interesting scenario. He states that time, dates, and other related factors don’t always work as expected in rendering because they shouldn’t matter too much for most websites. Even dynamic content usually doesn’t rely on highly accurate **** and time information.

Martin explains that the rendering process might not always be predictable in such cases. For example, if Googlebot crawls a page today but it wasn’t in the crawl queue for a day, the rendered page might show yesterday’s ****. However, if a resource was recently fetched and the cache was cleared, the rendered page could display today’s ****.

He emphasizes that relying on these kinds of tests is not very reliable, as they can produce weird results. Google’s rendering service tries to identify real-world website behaviors, and creating unusual test setups can interfere with its heuristics.

Martin also mentions that certain features, like web workers, might cause differences in rendering behavior because they are not widely used, and Google hasn’t prioritized implementing them properly. Similarly, requesting random numbers during rendering may result in pseudo-random numbers that are consistent across renders to maintain comparability over time.

TAKEAWAY: While it’s interesting to test how Google’s rendering service handles rapidly changing content, the results may not always be predictable or reflective of real-world scenarios. Google’s rendering process is designed to work effectively for the vast majority of websites and may not prioritize edge cases or uncommon implementations.

Is it possible that JavaScript rendering is off for a specific site for weeks or months during which Google only takes into account the source code?

According to Martin, it is generally unlikely that JavaScript rendering will be off for a specific site for an extended period while Google only considers the source code. He explains that everything typically goes into the render queue. 

However, he acknowledges that if things go “horribly wrong” due to creative JavaScript code, it might take Google a while to resolve or work around the issues.

In such rare cases, Google might use the available HTML from the server because it’s better than having nothing. However, Martin emphasizes that these situations are uncommon, and Google’s systems generally try to render everything.

What does Googlebot do if there is a “no-index” tag in the source code and “index, follow” in the rendered HTML?

Martin explains that if the source code contains a “no-index” tag, even if the rendered HTML contains “index, follow,” Googlebot will likely not attempt to render the page.

When Google sees the “no-index” directive in the HTML returned by the server, it concludes that the page doesn’t want to be indexed.

In such cases, Google can save on expensive processes, including rendering, conversion to HTML, and other related tasks.

If the page explicitly states that it doesn’t want to be indexed, Google can take a shortcut and move on. Removing the “no-index” directive with JavaScript does not work in this scenario.

What does Googlebot do if there is an “index” tag in the source and “no-index” in the rendered HTML?

In the case where there is an “index” tag in the source code but a “no-index” tag in the rendered HTML, Martin confirms that the JavaScript-injected “no-index” directive will generally override the initial “index” directive. However, he mentions some exceptions.

If the page has a significant amount of high-quality content, Google might decide to proceed with indexing.

In such cases, the non-rendered version might be indexed first, and then later overwritten by the rendered version. Depending on caching, this process can take a few hours to days to propagate across all data centers.

Martin notes that these are edge cases and happen rarely. While it’s possible for a page to be indexed for a short transitional period, it’s not reliable or predictable. The duration of this transitional period can vary based on data center load and geographic location.

Generally, it’s safer to assume that the page won’t be indexed. Martin advises providing clear signals to Google for the best results.

Is it OK in terms of SEO to block everyone coming outside the US?

From an SEO perspective, Martin advises against blocking users based on their location, such as preventing access to everyone outside the US. He argues that the internet is a global place, and people should have access to content regardless of their location.

Martin provides an example where a US citizen traveling abroad for a week would be unable to access the website from their location, forcing them to wait until they return home or use a VPN. He questions the point of such restrictions and suggests allowing access to the content.

If there are specific reasons for limiting access, such as reducing support efforts, Martin recommends clearly communicating this to the user rather than blocking them entirely. He believes that if users are aware of the implications and still wish to proceed, they should be allowed to do so.

While it is technically possible to implement geo-blocking, Martin considers it a poor user experience. He suggests it might be acceptable in some cases but generally advises against it.

How do I know if I have crawl budget issues?

Martin explains that the crawl budget consists of two components: crawl demand and crawl rate. Website owners may need to investigate different aspects depending on the limiting factor.

Crawl rate issues arise when a server cannot handle the volume of requests made by Googlebot. 

For example, if a website has a million products and Googlebot attempts to crawl them all at once, the server might crash if it can’t handle the simultaneous requests. In such cases, Googlebot adjusts its crawl rate by monitoring server response times and error codes (e.g., 502, 503, 504). It will reduce the number of concurrent requests to avoid overwhelming the server.

Crawl demand issues occur when Googlebot prioritizes crawling certain types of content based on factors like relevance, timeliness, and user interest.

For instance, a news website with a breaking story might see increased crawl demand as Googlebot tries to keep up with frequent content updates. On the other hand, content with low demand or seasonal relevance (e.g., Christmas shopping ideas in the summer) might experience reduced crawling.

To identify crawl budget issues, Martin suggests:

• Monitoring server logs for increased response times and error codes, which may indicate crawl rate issues.
• Checking the crawl stats report in Google Search Console for unusual patterns.
• Using the URL Inspection Tool to see if important pages are being crawled and updated frequently, especially for time-sensitive content.
• Analyzing crawl stats to see if Googlebot is spending time on irrelevant or unnecessary URLs, which may hint at a need to optimize site structure or sitemap.

Does Googlebot follow button links?

Martin clarifies that Googlebot does not treat buttons as links by default. If you want Google to recognize something as a link, it should be implemented using a proper <a> tag. However, he mentions that if there is a URL-like string within the button’s code, Google might still discover and attempt to crawl that URL, even if it’s not a true link.

For example, if a button on “example.com/a.html” contains a string like “example.com/b.html”, Googlebot might identify this as a potential URL and try to crawl it. However, this is not guaranteed, and the URL might be given lower priority compared to actual links.

TAKEAWAY: Martin emphasizes that to ensure Google properly recognizes and follows a link, it should be implemented using a standard <a href=""> tag. Relying on buttons or other non-standard methods may lead to inconsistent or suboptimal crawling behavior.

Does Googlebot follow JavaScript links?

Regarding JavaScript links (e.g., "https://seosly.com/blog/javascript-seo/javascript:void(0)"), Martin confirms that Googlebot does not follow them. If a link is created using the “javascript:” scheme, Googlebot will not execute the JavaScript code or interact with the link as it would with a regular URL.

However, similar to the case with buttons, if a URL-like string is present in the code, Googlebot might still discover and attempt to crawl that URL independently. This is not because Googlebot followed the JavaScript link but because it found a string resembling a URL.

TAKEAWAY:  Googlebot does not click on elements or interact with the page like a human user would. Since a “javascript:” URL cannot be directly requested via HTTP, Googlebot will not follow such links. Nevertheless, if a discoverable URL is present within the code, Googlebot might still find and crawl it separately.

Are JavaScript redirects OK? Is it better to have normal HTTP redirects?

Martin advises that HTTP redirects are preferable to JavaScript redirects whenever possible. HTTP redirects, especially permanent redirects (301), are more stable and robust, working consistently across browsers and search engines.

When a browser encounters a 301 redirect, it remembers the redirection and automatically requests the new URL in future visits, even if the user manually enters the old URL. This saves users additional network round trips and improves performance, particularly on slower networks.

In contrast, JavaScript redirects require the browser to first download and execute the JavaScript code before initiating the redirect. This introduces additional latency and may not work as seamlessly across different browsers or devices.

TAKEAWAY: From an SEO perspective, Googlebot can process JavaScript redirects when it renders the page, but it takes longer than HTTP redirects. With an HTTP redirect, Googlebot can handle the redirection immediately during the crawling stage, while a JavaScript redirect requires the rendering stage to take effect.

Martin mentions that Google’s own migration from Blogger to a new CMS platform required the use of JavaScript redirects due to platform limitations. While JavaScript redirects can work, he recommends using HTTP redirects whenever feasible for better performance and reliability.

How should SEOs talk to developers?

Martin advises SEOs to approach developers with proof and facts when discussing issues or requesting changes. He suggests:

• Showing developers the specific problem or challenge you’ve identified.
• Providing guidance from Google or other authoritative sources to support your case.
• Clearly stating the criteria for success and the expected impact of the changes.
• Following up after implementation to thank the developers and verify the results.

Martin emphasizes the importance of being honest about your level of knowledge. If you don’t understand something the developers told you, admit it and ask for clarification. Developers often don’t have all the answers either and may need to investigate further.

When proposing changes, provide measurable evidence, such as showing the rendered HTML, highlighting missing content, and referencing Google’s documentation. If you’re unsure about the specific technical implementation, ask the developers to explain what needs to be done so you can advocate for the necessary time and resources.

Be an ally to the developers, especially if they are willing to do the work but lack the priority. Help them make a case to stakeholders, such as team leads, project managers, or technical program managers, about why the requested changes are important and should be prioritized.

Should I be worried if there is a blank page with JavaScript disabled on a site?

Martin says there’s no need to worry if a page appears blank when JavaScript is disabled. Many websites rely heavily on JavaScript, and that’s generally fine. The key is to check the rendered HTML using tools like Google Search Console’s URL Inspection Tool.

You should be fine if the important content is present in the rendered HTML. However, if critical content is missing, you need to investigate further. Look into why the content is not there, which JavaScript components are responsible for it, and whether there are any apparent issues.

TAKEAWAY: As long as the essential content is available in the rendered HTML, there’s no cause for alarm. The presence of content in the rendered HTML is what matters most.

Will executing JavaScript with an SEO tool like Screaming Frog or JetOctopus reflect how Googlebot actually sees the site?

Martin explains that the results from SEO tools like Screaming Frog or JetOctopus might differ from what Googlebot sees for several reasons:

• Screaming Frog has its own rendering implementation, which may use different Chrome versions, specifications, flags, or approaches compared to Google’s rendering system.
• The tool runs from a different IP address than Googlebot, which can affect how the server responds. Some websites may block or serve different content to IP addresses that don’t match known Googlebot IPs.
• The website might use caching mechanisms that serve different versions to Googlebot and other tools.
• There could be glitches or inconsistencies in the website’s robots.txt implementation, allowing tools to access pages that Googlebot cannot.

While these variations are usually minor, they can sometimes lead to significant differences that are hard to debug. 

Debugging such differences can be challenging, but the URL Inspection Tool can help you understand why the discrepancies occur and what Googlebot encounters when crawling your site.

TAKEAWAY: If there’s a mismatch between what you see in Google Search Console’s URL Inspection Tool and Screaming Frog, trust the URL Inspection Tool as it reflects what the real Googlebot sees.

Should an e-commerce website have all the product boxes, product links, and pagination visible in the source code?

Suppose an e-commerce website is experiencing issues directly related to its reliance on JavaScript, such as products not showing up in the rendered HTML, slow product updates, or problems with Google Merchant Center. 

In that case, it might be worth considering a non-JavaScript implementation. This is particularly true if concrete data links the issues to JavaScript loading times and rendering.

However, Martin cautions against rebuilding the site without a compelling reason. Rebuilding introduces risks and complexities, especially if the development team is less experienced with the new technology. Implementing a hybrid or hydration-based solution can be more complex than a pure server-side or client-side rendering approach.

Before recommending a rebuild, ensure you have strong evidence that the JavaScript implementation is causing significant problems. If the current setup works adequately and the differences are minor, it may be best to stick with the existing implementation.

TAKEAWAY: Rebuilding a site is akin to migrating, which can be complex, time-consuming, and nerve-wracking. Unless substantial issues can only be resolved by moving away from JavaScript, it’s generally advisable to avoid rebuilding.

Related article: 40-Step SEO Migration Checklist

How does Next.js rehydration in a React-based site affect Google?

Martin confirms that Next.js rehydration in a React-based site does not have significant side effects from an SEO perspective. It’s generally fine and has no major implications.

The rehydration process may cause Google to discover links twice, but that’s not a problem. It doesn’t negatively impact the site’s visibility or performance in search results.

How many products will Google load with an infinite scroll?

Martin admits that it’s hard to definitively answer this question. In general, Googlebot does not scroll at all. If the content loading relies purely on scrolling, it won’t appear in the rendered HTML.

TAKEAWAY: There is no clear cut-off point or limit to how much content Google will load with infinite scroll. The best approach is to check the rendered HTML and make decisions based on what you find there.

While having different pagination implementations in the source code and rendered HTML is acceptable, Martin expresses some reservations about this approach. He considers it a shaky setup that may invite potential problems.

It’s best to make the pagination work without relying on JavaScript. If that’s not feasible, implementing different pagination types in the source and rendered versions can be an option. However, it’s important to know that this setup can be difficult to debug if issues arise.

Is it OK to link internally using URLs with parameters and canonicalizing those URLs to the version without parameters?

Martin believes that using parameterized URLs for internal linking and canonicalizing them to non-parameterized versions shouldn’t pose significant problems. If the parameterized URLs are correctly canonicalized, they will essentially point to the same destination as the non-parameterized versions.

However, he emphasizes the importance of providing clear signals to search engines whenever possible. The ideal scenario is if the website can use non-parameterized URLs for internal linking and canonicalization. It sends the clearest possible signal.

It shouldn’t be a major issue if technical limitations prevent using non-parameterized URLs. In such cases, the internal links primarily help search engines understand the site’s structure and aid in content discovery. 

TAKEAWAY: As long as the pages are properly indexed and ranked as expected, using parameterized URLs for internal linking shouldn’t be a significant problem, provided they are canonicalized correctly.

What are the worst JavaScript SEO mistakes you keep seeing repeatedly?

Martin highlights two common JavaScript SEO mistakes he encounters:

1. Trying to be clever and not using the platform’s built-in features: If there’s a native HTML solution, like using a regular link, developers should opt for that instead of trying to recreate the functionality with JavaScript. HTML elements often have built-in accessibility, performance, and discoverability benefits that need to be recreated from scratch with JavaScript. Developers often end up making things worse or just as good as the native solution, which begs the question of why they invested the extra effort.
2. Being overly aggressive with robots.txt and accidentally blocking important resources: Sometimes, in an attempt to be clever with SEO and minimize the number of URLs Googlebot crawls, developers get carried away with robots.txt rules. They might inadvertently block URLs that are essential for rendering the page correctly, resulting in content not showing up. Despite being a simple mistake, it still happens frequently.

JavaScript SEO best practices 

Here are the key JavaScript SEO best practices based on Google’s documentation, my conversation with Martin Splitt from Google, and a few awesome resources cited throughout this article, along with examples and additional points:

1. Use standard HTML links for navigation and internal linking.
   Example: Use <a href="https://seosly.com/products">Products</a> instead of JavaScript-based links like <a href="#" onclick="loadProducts()">Products</a>.
2. Ensure critical content is available in the initial HTML response.
   Example: For an e-commerce website, ensure the main product information, such as title, description, and price, is included in the server-rendered HTML rather than loaded exclusively through JavaScript.
3. Implement proper pagination using unique, crawlable URLs.
   Example: Use a pagination structure like https://example.com/products?page=1, https://example.com/products?page=2, etc., instead of relying solely on “Load More” buttons or infinite scroll powered by JavaScript.
4. Avoid relying on user interactions to load essential content.
   Example: Don’t hide important content behind tabs or accordions that require user clicks to reveal. If you must use such design elements, ensure the content is still present in the HTML source code.
5. Use server-side rendering or pre-rendering for important pages.
   Example: For a single-page application (SPA), implement server-side rendering or pre-rendering to deliver a fully rendered HTML version of the page to search engine crawlers.
6. Ensure JavaScript and CSS files required for rendering are not blocked by robots.txt.
   Example: Double-check your robots.txt file to ensure it doesn’t contain rules like Disallow: /js/ or Disallow: /css/, which would prevent Googlebot from accessing essential resources.
7. Optimize JavaScript code for performance.
   Example: Minify and compress your JavaScript files, remove unused code, and consider lazy-loading non-critical functionality to improve page load times.
8. Test your pages using Google Search Console and other tools.
   Example: Use the URL Inspection Tool in Google Search Console to see how Googlebot renders your pages and identify any indexing issues. You can also use tools like Lighthouse or Google PageSpeed Insights to assess performance and get optimization recommendations.
9. Provide fallback content and error handling for failed JavaScript execution.
   Example: If your page relies heavily on JavaScript, consider providing fallback content using the <noscript> tag to display information when JavaScript is disabled or fails to execute.
10. Implement lazy loading for images and videos.
    Example: Use the loading="lazy" attribute on <img> tags or a JavaScript lazy-loading library to defer loading below-the-fold images and videos, improving initial page load times.
11. Use meaningful HTTP status codes for error pages.
    Example: For a broken or removed product page, return a 404 HTTP status code instead of a 200 OK status with an error message. This helps search engines understand that the page is no longer available.
12. Monitor and address JavaScript errors.
    Example: Implement error tracking and logging mechanisms to identify and fix JavaScript errors that may occur on your website. These errors can impact the user experience and search engine indexing. JetOctopus is a tool that allows you to do that.
13. Use canonical tags correctly.
    Example: If you have multiple versions of a page (e.g., with different URL parameters), specify the canonical URL using the <link rel="canonical" href="https://example.com/products/main"> tag to indicate the preferred version for search engines to index. Ensure you are not putting conflicting directives in the source vs rendered HTML. 
14. Use noindex tags appropriately.
    Example: If you have pages that you don’t want search engines to index, such as thank-you pages or internal search results, include the <meta name="robots" content="noindex"> tag in the HTML <head> section of those pages. Again, ensure you are not putting conflicting directives in the source HTML vs rendered HTML. 
15. Ensure proper handling of noindex and nofollow tags in dynamically generated pages.
    Example: If you dynamically add noindex or nofollow tags to pages using JavaScript based on certain conditions, ensure Googlebot can correctly interpret and respect those tags when rendering the page.
16. Avoid using fragment identifiers (#) for essential content.
    Example: Instead of using fragment identifiers (e.g., https://example.com/#section1) to load different content on a page, use separate URLs with unique content (e.g., https://example.com/section1) to ensure search engines can properly index and rank the content.
17. Use the History API for client-side navigation in single-page applications.
    Example: When implementing client-side navigation, use the History API methods like pushState() and replaceState() to update the URL and maintain proper browser history.
18. Ensure JavaScript-rendered content is accessible and indexable.
    Example: Use the Fetch API or XMLHttpRequest to load additional content and update the page dynamically, ensuring the content is inserted into the DOM in a way that search engines can discover and index.
19. Use pushState() and replaceState() for dynamic URL updates.
    Example: When dynamically updating the content of a page without a full page reload, use the pushState() or replaceState() methods to update the URL in the browser’s address bar. This helps search engines associate the new content with a unique URL.
20. Implement proper HTTP status codes for redirects.
    Example: When redirecting users from an old URL to a new one, use a 301 (Permanent Redirect) HTTP status code to signal to search engines that the redirect is permanent and they should update their index accordingly.
21. Use descriptive and meaningful page titles and meta descriptions.
    Example: Ensure that each page on your website has a unique and descriptive <title> tag and <meta name="description"> tag that accurately summarizes the page’s content. These elements are important for search engine optimization and user experience. Make sure they are the same both in the source and rendered HTML.
22. Don’t forget about fundamental SEO rules.

JavaScript SEO tools 

You don’t need a plethora of tools to analyze and optimize your website for JavaScript SEO. 

Here are some of the most essential and useful tools, many of which are free or offer free versions:

Google Search Console – URL Inspection Tool

Google Search Console is a free web service provided by Google that helps website owners monitor, maintain, and troubleshoot their site’s presence in Google search results. 

The URL Inspection Tool within Google Search Console allows you to submit a URL and see how Google crawls and renders it. It provides information on the crawled and indexed status, any crawling or indexing errors, and the rendered HTML after JavaScript execution. This tool is essential for understanding how Googlebot sees your JavaScript-powered pages.

Google Rich Results Test

The Rich Results Test is a free tool provided by Google that allows you to test whether your page is eligible for rich results (such as review snippets, product snippets, or FAQ snippets) and preview how they might appear in search results. 

It validates the structured data on your page and provides feedback on any errors or warnings. For JavaScript-powered websites, it can help ensure that structured data is correctly implemented and can be parsed by search engines.

This tool also allows you to see the rendered HTML, so its purpose is not only to diagnose structured data. If you can’t access Google Search Console to view the rendered HTML, this is your tool to go. 

The retired Mobile-Friendly Test used to perform that function. How the Google Rich Results test can do it. 

Screaming Frog SEO Spider

Screaming Frog SEO Spider is a desktop application that crawls websites and analyzes various SEO aspects. While it is a paid tool, it offers a free version that allows you to crawl up to 500 URLs. 

One of its key features is the ability to render JavaScript and capture the rendered HTML. This can help you identify any discrepancies between the initial HTML response and the fully rendered page. Screaming Frog also provides insights into broken links, redirects, metadata, and other SEO elements.

JetOctopus

JetOctopus is a cloud-based website crawler and log analyzer tool that offers JavaScript rendering capabilities. It allows you to perform in-depth website audits, including analyzing JavaScript-rendered content. 

JetOctopus provides detailed reports on crawlability, indexability, and on-page SEO factors.

Chrome Developer Tools

Chrome Developer Tools is a built-in set of web developer tools within the Google Chrome browser. While it is not specifically designed for SEO, it provides valuable insights into how a web page is rendered and executed. 

You can use Chrome Developer Tools to inspect the DOM (Document Object Model) after JavaScript execution, analyze network requests, and identify any JavaScript errors. It also allows you to simulate different devices and network conditions to test your site’s responsiveness and performance.

Web Developer

Web Developer is a Chrome extension that adds a toolbar button with various web developer tools.

Among others, it allows you to disable JavaScript in the browser to analyze the JS reliance of the site you are auditing. 

Google PageSpeed Insights

Google PageSpeed Insights is a free online tool that analyzes a web page’s performance and provides suggestions for improvement. It evaluates a page’s mobile and desktop versions and provides a score based on various performance metrics. 

While it doesn’t directly analyze JavaScript SEO, it can help identify performance issues related to JavaScript execution, such as long script loading times or render-blocking resources. Improving page speed is crucial for user experience and can indirectly impact SEO.

Cora SEO Tool

Cora SEO Software is an advanced SEO diagnostic tool that analyzes up to 100K ranking factors to determine which ones have the most significant impact on a website’s search engine rankings. Among the factors it measures, Cora also evaluates numerous JavaScript-related factors that can influence a site’s SEO performance.

By examining these JavaScript factors, Cora can help you understand if and how your site’s JavaScript implementation affects your search engine rankings. 

JavaScript SEO FAQs (Frequently Asked Questions)

Here are a few of the most often-asked questions about JavaScript SEO. Some of them have already been answered in detail throughout this guide, but if you need quick answers, here they are. 

Do you need a JavaScript SEO agency to audit your website?

Whether you need a JavaScript SEO agency to audit your website depends on its complexity and your team’s expertise. If your website heavily relies on JavaScript and you’re experiencing issues with search engine visibility, working with an agency specializing in JavaScript SEO might be beneficial. They can help identify and resolve any JavaScript-related SEO issues and provide recommendations for optimization.

Is JavaScript SEO-friendly?

JavaScript itself is not inherently SEO-friendly or unfriendly. It’s the implementation of JavaScript that determines its impact on SEO. If JavaScript is used in a way that hinders search engines from properly crawling, rendering, and indexing content, it can negatively affect SEO. However, if implemented correctly, JavaScript can be SEO-friendly and enhance user experience.

How to optimize JavaScript for SEO?

Read this guide again! Here are the main points: 

• Ensure critical content is available in the initial HTML response.
• Use server-side rendering or pre-rendering for important pages.
• Implement proper internal linking using HTML links.
• Avoid relying on user interaction to load content.
• Optimize JavaScript code for performance and minimize file sizes.
• Test your pages using tools like Google Search Console to ensure proper rendering and indexing.

Are JavaScript redirects bad for SEO?

JavaScript redirects can be problematic for SEO if not implemented correctly. They may delay or prevent search engines from discovering and following the redirects. It’s generally recommended to use server-side redirects (e.g., 301 redirects) instead of JavaScript redirects whenever possible. If you must use JavaScript redirects, ensure they are properly configured and can be followed by search engines.

Is JavaScript bad for SEO?

JavaScript itself is not bad for SEO. However, improper implementation of JavaScript can lead to SEO issues. Some common problems include:

• Client-side rendering that hinders search engines from accessing content.
• Slow loading times due to heavy JavaScript execution.
• Content not accessible without user interaction.
• Improper internal linking or reliance on JavaScript for navigation.

If JavaScript is used correctly and follows best practices, it can be compatible with SEO.

Is JavaScript good for SEO?

When used appropriately, JavaScript can be good for SEO. It can enhance user experience, provide interactivity, and enable dynamic content. However, it’s crucial to ensure that JavaScript is implemented in a way that allows search engines to crawl, render, and index the content properly. When used in combination with SEO best practices, JavaScript can contribute to a positive SEO outcome.

How to make your JavaScript SEO-friendly?

Follow the JavaScript SEO best practices. To make your JavaScript SEO-friendly:

1. Use server-side rendering or pre-rendering to serve content to search engines.
2. Ensure critical content is available in the initial HTML response.
3. Implement proper internal linking using HTML links.
4. Avoid relying on user interaction to load essential content.
5. Optimize JavaScript code for performance and minimize file sizes.
6. Use structured data to provide additional context to search engines.
7. Test your pages using tools like Google Search Console to ensure proper rendering and indexing.
8. Consider using a progressive enhancement approach, where core functionality works without JavaScript.

What is the best JavaScript framework for SEO?

There is no single “best” JavaScript framework for SEO. A framework’s SEO friendliness depends on how it is implemented and optimized. Popular frameworks like React, Angular, and Vue.js can all be used SEO-friendly if best practices are followed, such as server-side rendering, proper internal linking, and efficient code optimization.

Do I need to take a JavaScript SEO course?

Taking a JavaScript SEO course can be beneficial if you want to deepen your understanding of how JavaScript impacts SEO and learn best practices for optimizing JavaScript-based websites. It can help you stay up-to-**** with the latest techniques and guidelines. However, it’s not an absolute necessity, as you can also learn through self-study, online resources, and practical experience.

Is SEO for JavaScript sites different?

SEO for JavaScript sites involves additional considerations compared to traditional static websites. Search engines face challenges in crawling, rendering, and indexing JavaScript-generated content. Therefore, SEO for JavaScript sites requires careful implementation to ensure search engines can properly access and understand the content. This may involve techniques like server-side rendering, pre-rendering, and following best practices for JavaScript SEO.

Does Bing JavaScript SEO exist?

Yes, Bing also considers JavaScript when crawling and indexing websites. Similar to Google, Bing can execute JavaScript and render web pages. However, Bing’s JavaScript rendering capabilities may differ from Google’s, and testing and optimizing your website for both search engines is important. Following JavaScript SEO best practices and ensuring your content is accessible and properly structured can also help improve your website’s visibility on Bing.

Does your website need a JavaScript SEO audit?

A JavaScript SEO audit is a comprehensive analysis of a website’s JavaScript implementation to identify and resolve any issues that may hinder search engine crawling, rendering, and indexing of the site’s content.

During a JavaScript SEO audit, a technical SEO will thoroughly review the website’s JavaScript implementation, analyze its impact on SEO, and provide detailed recommendations to improve search engine visibility and rankings.

This may involve a combination of manual analysis, tools, and testing to identify and resolve any JavaScript-related SEO issues.

If you want me to review your website in terms of JavaScript SEO, feel free to reach out to me using the contact form below or via my e-mail at [email protected]. However, keep in mind that my wait time is 6-8 weeks, and I am not the cheapest SEO on Earth. For cheap SEO services, go to Fiverr. 

This guide is super detailed, so it is possible that your developers will be able to diagnose and fix the issues after reading it. If they don’t, reach out to me.