Your website can look perfect in Chrome and still give Google an incomplete version of the business.

That gap usually appears when important content depends on JavaScript. A service description arrives from an API. A product grid appears only after someone clicks “Load more.” Navigation works like an app instead of a set of normal links. Visitors see everything, but a crawler may find an empty shell, broken route, or partial list.

Google does render JavaScript. That doesn’t mean every JavaScript implementation is search-friendly. Google describes processing these pages in three phases: crawling, rendering, and indexing. A page can wait in the rendering queue after its initial HTML has been fetched, and blocked resources or code errors can change what Google ultimately sees. Google’s JavaScript SEO documentation explains that process directly.

This audit gives a small business owner or marketer a practical way to find the expensive problems. You don’t need to become a JavaScript developer. You do need to know which pages matter, what to test, and what evidence to ask your developer for.

Start With the Pages That Make Money

Don’t begin by crawling every URL on the site. Begin with 10 to 20 pages tied to revenue:

  • The homepage and main service pages
  • Top product and category pages
  • Location pages, contact pages, and high-performing articles

Add any page launched or redesigned in the past 90 days. Include at least one weak page that should rank but doesn’t. This creates a useful test set without turning the audit into a month-long project.

Record each URL, its target search intent, whether it appears in Google, and the conversion action it supports. Google says Search Console can show how it crawls, indexes, and serves a website, so it should be your main source of evidence rather than a third-party visibility score. Google recommends checking Search Console after significant site changes and periodically during normal operation.

1. Compare Initial HTML With the Rendered Page

Open a priority page normally, then view its source. Search the source for a distinctive sentence from the main service or product description.

If the sentence is present, the server delivered it in the initial HTML. If it isn’t, JavaScript probably added it later. That isn’t an automatic failure, because Google can execute JavaScript. It is a warning that your visibility depends on successful rendering.

Next, inspect the URL in Search Console and run a live test. Review the rendered HTML or screenshot and search for the same sentence. Google’s troubleshooting guide says the URL Inspection tool can expose the rendered DOM, loaded resources, and JavaScript console output. Follow Google’s JavaScript debugging process for the exact test.

Ask your developer to investigate if the text is missing from the rendered result, if the rendered page shows a loading state, or if essential API requests fail. For high-value landing pages, server-side rendering or pre-rendering reduces this dependency. Google also says server-side or pre-rendering is a good idea because it can be faster for users and crawlers, while some bots can’t run JavaScript at all. That recommendation appears in Google’s JavaScript SEO basics.

2. Confirm Every Important Page Has a Real URL

A visitor clicking tabs in a single-page application may see the address bar change without receiving a genuinely crawlable page. Test each priority URL in a private browser window. Paste it directly into the address bar and refresh.

The right content should load without first visiting the homepage. The URL should also stay distinct when copied and shared. If /services/commercial-roofing/ falls back to the homepage, depends on a previous click, or displays an error after refresh, search engines and prospects are both getting a weak experience.

Google recommends the History API for client-side routing and warns against using URL fragments such as #/services to load different page content. Its JavaScript routing guidance includes working and broken examples.

The business test is simple: every service, product category, location, and useful resource deserves a stable URL that opens correctly on its own.

Right-click an important navigation item and look for the option to open it in a new tab. Then inspect the link if you know how. It should use an HTML anchor with an href pointing to a useful URL.

Buttons that run a JavaScript click handler may work for a person but fail as discovery paths for crawlers. Google states that it generally discovers links through <a> elements with href attributes. Google’s crawlable-link guide shows the supported format.

Check the main menu, footer, breadcrumbs, related-service cards, product-category links, and calls to action. Don’t assume the XML sitemap makes broken navigation harmless. A sitemap can help discovery, but internal links also communicate relationships and help visitors move toward a sale.

Give the developer a list of elements that behave like links but aren’t real links. The fix is often small, and it can improve keyboard access as well as crawling.

4. Inspect Titles, Descriptions, and Canonicals

Open the rendered source for each test page and verify three elements:

  1. A unique, descriptive title
  2. A useful meta description
  3. A canonical URL matching the preferred version of the page

JavaScript can change all three, but conflicting values create unnecessary risk. Google advises against using JavaScript to change a canonical to a different value from the canonical in the original HTML. It calls HTML the best place to set the canonical. Google documents that canonical behavior here.

Watch for several service pages that inherit the homepage title, staging-domain canonicals, or canonicals that change after rendering. Those are release-quality problems, not minor SEO polish.

Also compare what you see with Search Console’s inspected canonical. Google can choose a different canonical based on the signals it collects, even when you declare one. Google explains how canonical selection and duplicate crawling work.

5. Check Status Codes, Especially for Missing Pages

Visit a made-up URL such as /services/this-page-does-not-exist-9284/ and inspect its HTTP status. A missing page should normally return 404, not 200.

Client-rendered sites sometimes return the same app shell with a 200 response for every URL. The browser later displays “not found,” but the server has already told crawlers that the request succeeded. Google identifies this as a soft-404 risk and recommends using meaningful status codes. Its single-page application guidance offers server-side 404 and noindex approaches.

Repeat the check for discontinued products, retired services, private account pages, and redirects. Status codes are operating instructions. A pretty error message can’t replace them.

6. Make Sure Lazy-Loaded Content Doesn’t Require a Click

Scroll through product grids, galleries, testimonials, reviews, and long articles. Note anything that appears only after clicking, swiping, or scrolling.

Lazy loading can improve performance, but Google says the implementation should load relevant content when it becomes visible without depending on user actions. Google Search does not interact with a page the way a person does. Google’s lazy-loading guide recommends browser-native loading or viewport-based approaches.

The common failure is a “Load more” button that hides the rest of a product catalog from crawlable URLs. Another is a service FAQ whose answers don’t exist until a click triggers an API request. Test whether important text and URLs appear in Search Console’s rendered HTML.

Keep lazy loading for large images and secondary material when it helps. Move core sales copy, product names, prices, locations, and internal links into content that loads reliably.

7. Give Infinite Scroll and “Load More” a Crawlable Backup

If a category contains 80 products but its initial page exposes only 12, the remaining products need persistent discovery paths.

Google’s pagination guidance says crawlers generally don’t click buttons or trigger JavaScript functions that require user action. It recommends unique URLs for paginated pages and sequential <a href> links between them. Review Google’s pagination requirements before changing a product or article archive.

You can keep an infinite-scroll experience for shoppers while providing crawlable paginated URLs underneath it. Each page should show consistent content when revisited. Don’t canonicalize every paginated page to page one, because Google specifically advises each page to have its own canonical URL. The same Google guide covers correct pagination canonicals.

This matters beyond ecommerce. Blog archives, project galleries, testimonials, job listings, and review feeds can all hide valuable pages behind incremental loading.

8. Look for Blocked Scripts, APIs, and Rendering Errors

A page may work for your team because you’re logged in, close to the server, or carrying cached files. Googlebot gets a fresh request with different conditions.

In Search Console’s live URL test, review blocked resources and JavaScript errors. Check whether robots.txt blocks script folders, content APIs require authorization, or a consent tool prevents the main content from rendering. Google says it won’t render JavaScript from blocked files or blocked pages. Its processing overview explains how robots rules affect the crawl and render stages.

Ask the developer to log production JavaScript errors and separate essential content requests from analytics calls. Google’s Web Rendering Service may skip requests that don’t contribute to essential page content, and client-side analytics may not accurately represent its activity. Google recommends using Search Console crawl statistics for that monitoring.

Run the test on mobile, too. A responsive layout can use different navigation and loading logic even when the URL stays the same.

9. Retest After Releases, Plugin Changes, and Campaign Launches

JavaScript SEO isn’t a one-time certification. A new chat widget, cookie banner, page-builder update, or tag-manager rule can change rendering without changing the visible design.

Create a short release check for your priority pages. Confirm the live URL returns the expected status, the rendered HTML contains the main heading and offer, navigation links remain crawlable, and the canonical is correct. Then check Search Console again after Google recrawls the page.

Google says you don’t need to sign in to Search Console every day, but recommends reviewing it about monthly and when site content changes. Use that cadence as the minimum monitoring schedule.

Assign ownership. Your developer can fix rendering, but someone on the business side should verify that the pages tied to leads and revenue still work after a release.

Turn the Audit Into a Fix List

Grade each page with three labels: passes, needs review, or fails. Prioritize failures that affect the homepage, primary services, popular product categories, and location pages. A missing decorative animation can wait. A missing service description or undiscoverable product cannot.

For every failed check, document the URL, what a visitor sees, what Google’s rendered result shows, the expected result, and a screenshot. That gives a developer a reproducible problem instead of a vague request to “improve SEO.”

If your site depends heavily on JavaScript and you aren’t sure what Google can see, start a conversation with Your Web Team. We’ll trace the path from server response to rendered page and focus the fix list on the pages that produce business.