JavaScript SEO Audit for Agencies: What to Check on Client Websites

A client says their website is indexed, so JavaScript SEO must be fine.

Another says their site is built with React, so it must need prerendering.

Neither conclusion is strong enough for an agency recommendation.

A useful audit tests what important crawlers actually receive, identifies the affected page templates and separates rendering problems from access, routing, metadata, content and visibility gaps.

Quick answer

An agency JavaScript SEO audit should compare three versions of representative client pages:

1. Raw server response.
2. Completed rendered HTML.
3. Relevant crawler-facing response.

For each version, verify status, title, H1, main content, links, canonical, robots directives, structured data and freshness.

Then classify each finding as healthy, access issue, rendering issue, routing issue, indexability issue, stale content or non-technical visibility gap. Recommend prerendering only when a relevant crawler misses important public JavaScript content and the current architecture cannot address it more directly.

Begin with scope and authorization

Before testing, agree on:

• domains and environments in scope
• public versus authenticated pages
• target markets and languages
• search and AI crawlers relevant to the client
• access rules the client intends to maintain
• recent migrations or deployments
• business-critical page types
• analytics and Search Console access, if included
• deliverables and limitations

Do not test private routes as though they should be public. Do not recommend bypassing authentication, robots rules or security controls without explicit client authorization.

The audit should answer a business question:

Can the systems this client cares about retrieve accurate, current and useful content from the public pages that support discovery?

Inventory the technology without diagnosing from it

Record the visible architecture:

• framework or site builder
• client-side, server-side or static rendering behavior
• CMS and content APIs
• hosting and CDN
• redirects and edge middleware
• bot-management or firewall layer
• localization approach
• prerendering service, if any
• sitemap and robots.txt location

This helps explain the request path. It does not determine the finding.

A React website may return complete server-rendered HTML. A traditional CMS may insert critical product data through client-side JavaScript. Test the deployed page, not the technology label.

Sample by page template, not random URLs

Choose representative URLs from each important template:

• homepage
• product or service
• pricing
• blog or resource
• documentation
• integration
• location or language version
• dynamic product or listing detail
• paginated or infinite-scroll collection
• error page

For a small site, one or two URLs per template may be enough for initial diagnosis. For a large catalog, increase the sample across categories, data states and recently changed pages.

Record why each URL was selected. This makes the audit reproducible and exposes coverage limits.

Layer 1: raw server response

Inspect what the server returns before browser JavaScript executes.

Check:

• HTTP status and redirect chain
• final production URL
• title and meta description
• canonical
• robots meta and X-Robots-Tag
• H1 and main body content
• crawlable internal links
• structured data
• language and alternate links
• loading, error or empty-state text

Measure required content, not generic word count. A concise landing page can be healthy; a long navigation shell can still lack the information that makes the route unique.

Layer 2: completed rendered HTML

Render the page in an appropriate browser environment and inspect the DOM.

Google's JavaScript SEO guidance recommends checking rendered HTML with its URL Inspection tool or Rich Results Test.

Compare whether rendering:

• adds the expected primary content
• changes the title or canonical
• creates or removes indexability directives
• produces standard links with meaningful destinations
• loads the correct route
• completes without error or timeout
• adds structured data that matches visible content

Keep both readable differences and captured evidence. A green score without the underlying HTML is difficult to explain or verify.

Layer 3: relevant crawler-facing response

Request the same page through the intended crawler profile and public delivery path.

Check:

• robots.txt policy
• firewall or bot-management response
• status and redirects
• rate-limit or challenge page
• content and metadata parity
• current cache or release version
• regional differences where relevant

Identify the crawler and its purpose precisely. A training crawler, search-discovery crawler and user-requested fetcher are not interchangeable.

Do not assume that successful Google rendering proves every AI or search crawler receives the same content.

Audit content that requires interaction

Important information should not depend on an action a crawler is unlikely to perform.

Google's lazy-loading guidance says Google Search does not interact by scrolling or clicking to load content.

Check whether key content requires:

• clicking a tab
• accepting a non-essential prompt
• typing into a field
• scrolling to trigger an API call
• opening an accordion implemented without content in the DOM
• selecting a location before any public information appears

The correct fix may be information architecture or progressive enhancement, not prerendering.

Check URL and routing behavior

JavaScript applications can look correct through in-app navigation while failing on a direct request.

Test:

• direct loading of deep routes
• refresh on a deep route
• browser back and forward navigation
• correct status for missing pages
• unique URL for distinct public content
• stable canonical after client-side navigation
• query parameters and filters
• pagination or infinite scroll

Look for soft 404s, homepage content returned for every route and 200 responses for real errors.

Check internal discovery

A rendered page can be readable but poorly connected.

Verify:

• important pages are linked from crawlable navigation or contextual links
• anchor text describes the destination
• links use real href values
• orphan pages are included appropriately in sitemaps
• paginated content has discoverable URLs
• locale variants connect correctly

JavaScript click handlers without usable anchors can create a discovery problem even when the destination renders correctly.

Check parity and freshness

Compare the primary information users and crawlers receive.

Look for:

• outdated prices or product claims
• missing sections in one response path
• crawler-only copy
• stale rendered cache
• mismatched structured data
• different canonical or robots directives
• different locale or route content

Equivalent does not require identical HTML. Navigation wrappers and interactive controls may differ. The main facts, purpose and claims should not materially conflict.

If a cache serves an old version, classify it as freshness rather than assuming rendering failed.

Separate technical access from AI visibility

The audit can confirm that important pages are accessible and readable. It cannot prove the brand will be selected for a generated answer.

Use separate observations:

• crawler access
• content delivery
• search indexing and performance
• AI mentions
• AI citations
• AI recommendations
• competitors and sources

If the technical audit passes but the brand is absent from relevant prompts, investigate relevance, coverage, evidence and external sources.

Read AI Crawler Access vs AI Visibility for the complete distinction.

Classify findings before recommending fixes

One finding can have dependencies. Fix a blocked crawler before judging its rendering output.

When to recommend prerendering

Prerendering may be appropriate when:

• important public content depends on browser JavaScript
• a relevant crawler misses that content
• URLs, directives and access policy are otherwise correct
• server-side or static rendering is not a practical immediate change
• output can remain equivalent to the user page
• the agency can monitor cache freshness and parity

Google's dynamic rendering documentation calls dynamic rendering a workaround rather than its recommended long-term solution. Include that trade-off in the client recommendation.

Prerendering should solve a demonstrated delivery problem, not become a standard add-on for every website.

Build an evidence-based client deliverable

The report should include:

1. Scope, target crawlers and sampled templates.
2. Executive summary in plain language.
3. Raw, rendered and crawler-facing comparisons.
4. Findings grouped by severity and type.
5. Affected URLs and likely template scope.
6. Recommended action, owner and dependency.
7. Implementation acceptance criteria.
8. Monitoring plan after remediation.
9. Explicit limits and untested areas.

Use screenshots for orientation, but include HTML excerpts, status data and source URLs for technical evidence.

Use severity consistently

Critical

Important sections are inaccessible, empty, incorrectly blocked or materially deceptive across a major template.

High

Canonical, routing, freshness or content failure affects a significant page group.

Medium

An issue reduces clarity or discovery but does not remove the entire page.

Low

Limited cleanup, minor inconsistency or recommendation with low immediate impact.

Severity should describe risk and scope, not the amount of work the agency wants to sell.

Verify the remediation

An audit is incomplete if the agency never checks the implemented fix.

After release:

• repeat the original request profiles
• confirm required content and metadata
• compare the affected templates
• verify content parity
• confirm cache freshness
• record the release date
• enable ongoing monitoring

Use How to Monitor JavaScript SEO After Every Website Deployment as the ongoing control.

Who this is for

• SaaS founders with already-shipped JavaScript websites
• React, Vite, Vue, Lovable, Bolt, or Base44 users
• SEO freelancers checking crawler-readable HTML
• Agencies maintaining client sites without rebuilding them

Where Prerender Buddy fits

Prerender Buddy can give an agency one connected workflow:

• compare raw and rendered output
• inspect crawler-facing pages
• determine whether prerendering is necessary
• verify the implementation
• monitor page health and freshness
• measure AI visibility separately
• turn gaps into prioritized actions

This helps the agency sell diagnosis and ongoing visibility work rather than a one-time installation.

What the audit cannot guarantee

The audit cannot guarantee:

• crawling or indexing on a schedule
• search rankings
• AI mentions, citations or recommendations
• traffic, leads or revenue

It can show whether the client's public content is technically available through the tested paths and what should be corrected when it is not.

You may not need Prerender Buddy if

• Server HTML is already complete.
• Static pages crawl correctly.
• You are already rebuilding with SSR or static generation.
• You only need an audit, not a rendering fix.

Final recap

Audit deployed behavior, not framework labels.

Sample by page template, compare raw, rendered and crawler-facing responses, test routing and interaction requirements, verify parity and freshness, and separate technical eligibility from answer visibility.

Give the client evidence, classification and a prioritized remediation plan. Recommend prerendering only when the test proves it is the appropriate bridge.

Use the JavaScript SEO Score for a fast initial client-page baseline, then turn the accepted audit findings into a multi-client monitoring workflow.

Need a repeatable way to audit client crawler visibility? Start a Prerender Buddy project and compare the responses that matter.

Frequently asked questions

What should a JavaScript SEO audit include?

Include representative page templates, raw and rendered HTML, relevant crawler responses, status, routing, content, links, canonicals, robots directives, structured data, freshness and remediation priorities.

Does every React client need prerendering?

No. Test the deployed response. A React site may already be statically generated or server-rendered, or the relevant crawler may receive the content correctly.

How many client URLs should an agency test?

Start with representative URLs from each important template. Increase the sample for large, dynamic or inconsistent page groups. State the sample and limitations in the report.

Can the audit test AI crawler access?

Yes, for identified public crawler request paths and policies. The test can show access and delivered content; it cannot guarantee a mention or citation in an AI answer.

Is a screenshot enough evidence?

No. Include status, redirect, HTML, metadata, request profile and timestamps. A screenshot can look correct while the underlying DOM or crawler response remains incomplete.

Should agencies promise rankings after fixing JavaScript rendering?

No. The fix makes content technically available. Search engines make separate decisions about crawling, indexing and ranking.

How often should an audit be repeated?

Repeat affected tests after remediation and major migrations. Keep automated checks on critical templates after deployments and on a schedule.