Single Page Analysis : audit any URL in seconds

Diagnose a page on the spot, no full crawl required

A full crawl is the right move when you want to understand a whole site. But when the question is about one URL – a homepage, a core money page, a competitor's product template – spinning up a whole audit might be overkill.

The Single Page Analysis tool renders a single page in real time and hands you the full technical analysis in moments. Paste the URL, click Check, done. It uses the Chrome Crawler, Sitebulb's user agent and a mobile device, so the page is analyzed the same way it would be in a full audit.

It's fast enough to use live, too. Pull up a prospect's page mid-call and talk through what you're seeing while they're still on the line.

One URL, the full picture

When you run a check, Sitebulb works through all the same Hints checks it would in a full report, then lays everything out across a set of tabs:

• Overview: The headline data in one place: indexability, metadata and key on-page elements, technologies, Core Web Vitals and performance, the HTTP response and response headers, and international implementation.

• Hints: Every issue flagged during the analysis of your URL, just as you'd see them in a full audit.

• Code Coverage: How much of the CSS and JavaScript loaded by the page is actually used to render it, exactly like the main Code Coverage report.

• Response vs Render: A side-by-side comparison of the raw HTML response and the JavaScript-rendered DOM.

• Screenshots: The rendered page on both desktop and mobile.

• Outgoing Links: Every internal and external link on the page, with its supporting data.

• Page Resources: An organized list of all stylesheets, JavaScript, fonts and images.

• Lighthouse: Mobile and desktop scores, right next to all the other page data so you can cross-check performance against everything else.

See exactly what JavaScript is doing to your page

Almost every site leans on JavaScript these days. Google increasingly renders it in the browser, and most LLMs can't render it at all, so the gap between your raw HTML and your rendered page is one of the most important things to understand about any URL.

The SPA's Response vs Render tab shows both side by side. Content modified by JavaScript is highlighted in orange, content added by JS in green, and anything removed by JS in red. So you can see at a glance whether elements like titles, canonicals, meta robots directives or internal links only show up after JavaScript runs. That's a common way for pages to fall out of the index without anyone noticing.

Drill into the differences across the DOM, Links, Images, Page Text and HTML. It's the Response vs Render report experience, focused on the single page in front of you.

Dial in your crawl settings before you commit

The SPA started life as our own internal troubleshooting tool, and it's still the fastest way to sort out a crawl that won't behave. Rather than setting up and running a whole new audit every time you want to test something, try it on a single URL first.

A few things it's brilliant for:

• Trouble starting a new project: Your start URL needs to return a 200 before you can set up an audit. If it's redirecting or throwing an unexpected response, the SPA shows you the actual HTTP response so you can find a start URL that works.

• 403s and "server rejected the request" errors. Some servers have strict protections and block Sitebulb's default user agent. Open the Settings drop-down, switch to a pre-allowlisted or authorised user agent, and re-check the URL, testing different UAs in seconds instead of running a fresh crawl for each one.

• Choosing HTML vs Chrome Crawler. The HTML crawler is faster, but JavaScript-heavy sites need the Chrome Crawler for accurate results. Run a key page through the SPA, check Response vs Render, and you'll know straight away whether content is being created, modified or deleted by JavaScript.

• Rendering issues and missing content. Test different Advanced Chrome Crawler configurations on one URL and use the Screenshots tab to confirm the page is rendering correctly before you apply those settings to the whole audit.

Once a single page behaves as expected, you can run the same settings across a full crawl with confidence. Find out more in our Crawler Settings docs.

Confirm your fixes actually worked

Pushed a change to production and want to know if it fixed the issue? Re-run the URL through the SPA and check the result there and then, rather than waiting for the next full crawl to come around. It's a quick way to confirm a problem is genuinely resolved, and to keep an eye on how a template is shaping up as a migration rolls out.