Buying a Technical SEO Audit for React and Angular Apps

Buying a technical SEO audit for a single-page app is one of those purchases where the deliverable can look perfect and still be wrong. The PDF is polished, the donut charts are green, and somewhere in production your <title> still says “React App.”

I’ve watched teams pay five figures for an audit that crawled the shell, skipped JavaScript, and filed a clean report. The shell was clean. The actual pages had no H1s, no canonicals, and meta descriptions that still said “placeholder.” Nobody noticed until rankings slid and someone finally compared the raw HTML to what a browser loaded.

Here’s what to ask for before you sign, whether you’re hiring an agency or buying a tool.

The audit has to render the page

If the crawler doesn’t execute JavaScript, you’re paying for a report on index.html, the file your build tool produces before React or Angular do anything interesting. That file is almost always clean, and it’s almost never what users or Google end up with.

A real SPA audit renders every URL in a real browser engine, waits for the app to finish loading data, and audits the result. Every URL, not a sample and not the first 500. If a vendor can’t explain how they render JavaScript in one sentence without the word “hybrid,” move on. The JavaScript rendering failures that fool most crawlers are the whole reason this purchase is tricky.

What a real SPA audit covers

At minimum:

• A rendered crawl of every URL. Headless Chrome or equivalent, running your actual bundle.
• Raw versus rendered comparison. The canonical that only exists after hydration, the H1 that’s blank until an API call returns, the meta description that’s a placeholder in the shell. If you can’t see both versions, you can’t tell what Google depends on rendering to find.
• Route discovery. Links that only appear after the router mounts need to be found and followed. Navigation built on click handlers instead of <a href> needs to be called out, because Google won’t follow it either.
• Router status codes. Soft 404s where the app shows a “not found” component and the server returns 200.
• Metadata on deep links. Titles and canonicals that are right when you click through from the homepage and wrong when a URL is loaded cold, which is how Google loads it.
• Performance on rendered pages. Render-blocking scripts, bundle weight, unsized images, and a slow LCP element measured against the page your users actually get.
• Blocked resources. robots.txt rules that stop Google from fetching the JavaScript that builds the page.

Questions to ask before you sign

Make them answer out loud, and then in writing:

1. Do you render every URL, or sample? What’s the page cap, and what happens at URL 501?
2. Will I see raw HTML and rendered HTML for each URL, or only the rendered version?
3. How do you find routes that aren’t in the sitemap or the initial HTML?
4. Can you crawl staging before launch, including environments behind a VPN?
5. Do you compare the crawl against our server logs, so we know which pages Googlebot actually requests?
6. Can I get the raw data as JSON or CSV, or only a PDF?
7. Will the findings be grouped by route or component, so my programmers know what to change?

If they hedge on the first two, the rest of the conversation doesn’t matter.

Deliverables your programmers can use

A PDF with a score on the cover is what you forward to a VP to prove the work happened. A programmer can’t open a ticket from it. What you want is a list of issues tied to URLs and grouped by route or template, exported as JSON or CSV, that someone can drop into a ticket or turn into a check that runs before every release. For large React and Angular apps, the enterprise SPA audit playbook shows what that looks like in practice.

Doing it yourself

You don’t always need to hire someone. If your team can read a crawl export, you can run the rendered audit yourself before deciding whether you need outside help.

Black SEO Analyzer runs locally, so staging behind a VPN is just another URL. With --spa it renders every page in headless Chrome and audits the rendered DOM, with no page cap. Crawl once without rendering and once with it, compare titles, canonicals, and H1s per URL, and you have the raw versus rendered diff most vendors charge for. Output comes as JSON, CSV, XML, or an HTML report, and it’s a one-time license rather than a retainer.

If you’re scoping an audit and the proposal doesn’t mention rendering once, run a crawl on a section of the site you’re confident about first. It makes the vendor conversation a lot shorter.

BSA renders React and Angular apps in headless Chrome and audits what actually loaded. See the features or try it free for 14 days, no page limit, no credit card.

-Sethers