Does a website audit work on a custom built site?
Your platform is invisible to most conversion checks and decisive for exactly two. Here is which two, and the four-minute view-source test that tells you whether any audit tool can read your site at all.
"My site is custom built, so an audit tool will not understand it." Mostly wrong, and the real exception is not the one you are worried about. A conversion audit reads the rendered page, which makes your platform invisible to most checks and decisive for a narrow few.
The belief is reasonable. Every audit tool's homepage lists Shopify, WordPress, Webflow. Every signup form has a platform dropdown. If you hand-built your site, you have been trained to expect the form to turn you away.
What it misses is where the reading happens. A crawler never opens your admin panel. It requests the URL, runs the JavaScript, and reads what comes back. Your headline, your form, your fold all exist in that rendered page whether a CMS put them there or a person did.
Does a website audit work on a custom built site?
Yes, for almost everything an audit checks. Copy, offer, trust, layout and performance checks all read the rendered page, so a bespoke build gets read exactly like a templated one. Your platform matters in two places only: the code a fix ships as, and any check that reads a platform's own files.
- 32.1% of websites run none of the content management systems W3Techs monitors, surveyed 23 October 2026
- 100% of HTML pages rendered in full for Googlebot across more than 100,000 measured fetches
- 27 platforms Revslip fingerprints, a number that shapes the fix code and gates nothing
Platform shares from the W3Techs content management survey. Render figures from the MERJ and Vercel crawl study, measured through April 2024.
Which checks care about your platform, and which never ask?
Messaging, trust and content checks never ask, because they read words and structure sitting on the page. Performance checks read your own server response, which is yours whatever built it. Revslip runs roughly 200 signals across six categories, and your platform changes the answer in none of them.
Here is the thing that confuses people. That dropdown is a routing question, not a permission question. It tells the tool which fix to write and which arithmetic to price against. It is not asking whether it can read you.
Revslip's routing works exactly that way. Business type picks the model, ecommerce against SaaS against lead generation. The tech stack fingerprint picks the framework the generated fix components get written in. Neither one decides whether the crawl runs.
Curious what yours scores? Paste the URL and find out.
Why rendering decides what a tool sees, and your platform does not
Because there are two versions of your page. The raw HTML your server returns, and the rendered page after JavaScript finishes. On a client-rendered custom app the first one can be an almost empty shell. A tool that does not execute JavaScript reads that shell and finds nothing to judge.
Google's own documentation sets out the three phases plainly: crawl, render, index, with "a headless Chromium" running the JavaScript before anything gets indexed. Revslip does the same thing in its own pipeline, capturing desktop and mobile screenshots plus a full-page render and reading those next to the HTML.
So the question that decides your outcome is not "is my site custom". It is "does this tool render". Those are different questions, and only the second one can disqualify you.
How far does the rendering evidence actually go?
Further than the folklore, with a long tail worth knowing about. MERJ and Vercel instrumented more than 100,000 Googlebot fetches in April 2024 and matched 37,000 render beacons against server logs. Every HTML page in that sample got rendered. Half of them rendered inside ten seconds of the crawl.
The tail is real: the 90th percentile sat near three hours, the 99th near eighteen. The authors call the long waits the exception rather than the rule, a fair reading of their data and also one from a company selling a rendering framework.
Now the awkward part, about the other number. That 32.1% gets quoted as "a third of the web is custom built". It does not say that. It says a third runs no CMS the survey can detect, which bundles static site generators, headless setups and systems the fingerprint misses. Nobody has a clean count of bespoke sites, including us.
How do you check what a crawler gets from your site?
Four minutes, no tools beyond a browser. You are comparing the raw response against the rendered page and hunting for your own headline in the first one. If it is missing there, you have found the only platform-shaped problem that actually matters.
- View source, not inspect. Right-click, then View Page Source. That is the raw response, before any JavaScript runs.
- Search it for your headline. Find the exact words. Present means server-rendered, and every tool can read you.
- If it is absent, check the render. Run the URL through Google's URL Inspection tool or the Rich Results Test and read the rendered HTML it hands back.
- Compare the two. Content in the render but not the source means your site is client-rendered, and any tool without a headless browser sees a blank page.
Google documents both tools for this check and tells you to confirm the rendered HTML carries the content you expect. The three-phase description sits alongside it.
What a custom build changes about the fix, not the finding
The finding reads the same sentence either way: your headline names a feature, your form asks nine questions, your proof sits below the claim it supports. What changes is the shape the fix arrives in. On a recognised stack it comes back as code. On a bespoke one it comes back as a description.
Does this work on a Next.js or Nuxt site?
Yes, and better than average, because both server-render by default. Next.js is one of the 27 stacks Revslip fingerprints, so fix code returns as components in your framework rather than as prose.
What if my site uses no CMS at all?
Nothing changes for the audit. A static HTML site is the easiest thing a crawler can read. You will make the edits by hand instead of in an admin panel, which is a deployment question, not an audit one.
What about pages behind a login?
Not crawled, on any platform. If your product only shows its value after signup, the audit covers your public pages and stops at the door.
Want the ranked list instead of the theory? Run a free audit.
Where a custom build genuinely breaks the audit
Three places, all of them downstream of the finding. Generated fix code on a stack the fingerprint cannot name. Any check that expects a platform's own files. And the limits that land on everybody: no session recordings, no heatmaps, no accessibility conformance review, no domain-scale crawl of canonicals and hreflang.
The build we are worst on A client-rendered front end on a stack we cannot name gets the weakest version of Revslip: findings still land, generated components come back generic, and your developer adapts them. Run the view-source check above before spending anything, and if your headline is missing from the source, budget for doing that translation yourself.
One more note on our own evidence. The 134 or so businesses Revslip has audited are not a random sample. They are sites whose owners already suspected something was wrong, the wrong population to generalise from. It shows the checks run across stacks, and says nothing about how your sector converts.
So the objection shrinks. Your site being custom is not the reason an audit would fail you. A page that only exists after JavaScript runs is, and you can settle that in four minutes.