Technical SEO
JavaScript rendering audit
This is the narrowest useful unit of Technical SEO: make sure the content you think you published is actually in what search engines and models receive.
In plain terms, what is a JavaScript rendering audit?
Make sure the content you think you published is actually in what search engines and models receive. In practice that means comparing raw HTML against rendered HTML for every important template, and then the harder half: identifying content, links and markup that exist only after JavaScript runs.
Why this work exists
Nothing about this is difficult. It is just rarely anybody’s job, so it waits.
It sits inside Technical SEO, which is the broader discipline, and it is the part people most often ask for by name.
The nearest piece of work to it is working out why a page that renders fine still returns nothing to a crawler. Where that is already handled, this moves faster than the estimate; where it is not, the two get done together or neither of them holds.
What good looks like
The useful version ends with a decision somebody can act on this month, not a report somebody files.
The gap between that and where most accounts start is why this is scoped as JavaScript rendering audit rather than as a line inside something larger. Finding the template change that quietly dropped the canonical tags is the usual second step once it is in place.
When this is the right work
This is the right work when any of these is true:
- The page looks right in a browser and the cached version is nearly empty
- Internal links are built by script and never followed
- Content appears only after a user interaction
If none of those is true, something else is probably the constraint, and the Technical SEO overview maps the alternatives. The usual neighbours are measuring the site on the phone and connection the customers actually have and cutting the third-party scripts nobody can name an owner for.
What the work covers
The scope, stated plainly:
- Comparing raw HTML against rendered HTML for every important template, scoped against what the business can actually act on rather than what is possible.
- Identifying content, links and markup that exist only after JavaScript runs. Straightforward in principle; the detail is where it stops being quick.
- Testing what happens when a script fails, times out or is blocked, which clients tend to want evidence for, so it is documented as it goes.
- Choosing and implementing the right rendering strategy per template, handled before the parts that depend on it rather than alongside them.
How it runs
It runs in three passes. The order is not interchangeable.
Checking it held
Changes get re-checked after a fortnight, because a surprising number of them do not survive the next deployment or the next platform update.
Handing it over
Whatever is left running ends up with a named owner and a schedule, or it stops happening within two months.
Agreeing the measure
The number this will be judged on is fixed before the work starts. Agreeing it afterwards is how both sides end up disappointed.
What each part runs into
In practice each of those four runs into something specific:
- Comparing raw HTML against rendered HTML for every important template, where a London engagement contends with an incumbent whose position comes from presence rather than effort
- Identifying content, links and markup that exist only after JavaScript runs – working in Los Angeles this means accounting for a buying pattern that resolves faster than the reporting cycle
- Testing what happens when a script fails, times out or is blocked, and in Toronto the constraint on it is a sector mix that pulls the brief in several directions
- Choosing and implementing the right rendering strategy per template, harder in Jaipur because of a seasonal peak that arrives before the content is indexed
The error worth naming
Assuming that because one crawler executes JavaScript, all retrieval systems do. Many do not, including several that build AI answers.
It is the reason this work sometimes looks like it does not work.
How it is measured
Parity between raw and rendered HTML for content, links and structured data. It is reported with the existing metrics rather than replacing them, because a new number nobody recognises persuades nobody.
The definition is written down once and not quietly adjusted when it becomes inconvenient.
What you end up with
The output is a template-by-template rendering report with the gaps closed and a rendering approach documented for new work.
It is yours, in a format you can edit, whether or not the engagement continues.
How it differs by sector
The brief changes with the sector, not just the emphasis:
- In Nonprofit and NGO the binding constraint is that two audiences with nothing in common: donors and the people served.
- Legal and professional services: the thing that changes the scope here is that high-value, high-intent local search under advertising rules that vary by jurisdiction.
- For Education and training, admission cycles, a parent paying for a student’s decision, and course-level demand. and that shapes how far this can go.
The industry pages carry the rest of that detail. Nonprofit and NGO and Legal and professional services are the two where this piece of work most often decides the outcome.
Common questions
Do search engines execute JavaScript?
The major one does, with a delay and a budget. Many other systems that matter, including several retrieval layers behind AI assistants and most social preview fetchers, do not or do so inconsistently. Content that only exists after JavaScript runs is therefore visible to some systems and invisible to others.
What is the safest rendering approach?
Server-rendering or pre-rendering the content, links and structured data that need to be found, and leaving JavaScript for interaction rather than for content delivery. Where that is not possible, dynamic rendering is a workable fallback, though it adds a cache that can silently serve stale content.
What happens if we stop after this?
You keep everything: A template-by-template rendering report with the gaps closed and a rendering approach documented for new work. Documented so your own team can continue it, including the parts we would have done next and why. Content and Editorial for B2B services is the counterweight to Brand and Creative for B2B services, and both are worth half an hour.
What if we disagree with the diagnosis?
Then we look at the data together. Parity between raw and rendered HTML for content, links and structured data is the test, and a finding that cannot survive being questioned is not a finding worth acting on. If a number has to be defended at the end of the quarter, AI Platform Optimization in Ahmedabad and Analytics and Measurement in Ahmedabad are where that starts.
Does anything need doing before JavaScript rendering audit?
Sometimes. The signals above are the honest test, and where something upstream is the real constraint we will name it even though it is not the work on this page. The cheapest version of this is in Attribution and incrementality. The one that lasts is in Consent and privacy-safe measurement.
Ask about javascript rendering audit
Tell us what you have tried already. That is usually the fastest route to a useful reply.
Let us look at where you actually stand
Tell us what you sell and what is not working. We will come back with the two or three things we would look at before anything else.