How to check a website for problems

Walk the golden path as a stranger

Open your site in a private browser window on your phone, not on the desktop machine you built it on. The reason this matters is that you can no longer see your own site as a stranger does: you're logged in half the time, your browser has years of autofill and cached assets smoothing over things that would otherwise stall a first-time visitor, and you know where every button sits without needing to look, so friction that would make someone else give up never registers as friction to you. Try to do the one thing an actual customer came to do - find a price, book a slot, call, or buy - and note every point where it gets harder than it should: a form field that resets when autofill misfires, a button sized for a mouse cursor sitting under a thumb, a popup that appears before you've read anything and won't close cleanly. This ten-minute exercise consistently surfaces problems that no automated tool ranks highly enough, because tools measure what's technically broken, not what makes a real visitor quietly leave.

Click every link in your navigation and footer

Links break quietly and continuously as a site evolves: a page gets renamed for a cleaner URL, a product is discontinued and its page removed without anyone updating what pointed to it, a blog gets restructured, or an external site you once linked to simply goes offline. None of this happens all at once, which is exactly why it accumulates unnoticed - each individual change looks harmless when it's made. The result over months or years is a navigation menu, footer, or set of commercially important pages riddled with dead ends that visitors and search crawlers both hit without warning. Redirect chains cause a subtler version of the same problem: a link that bounces through two or three redirects before landing on its real destination still technically works, but it adds load time and can dilute the ranking signal search engines were trying to pass through. Checking navigation and footer link by link catches the obvious breaks; running a crawler across the whole site catches the redirect chains and orphaned pages a manual click-through would miss.

Measure speed with real data, not vibes

Your own site feels instant to you because your browser has already cached most of its images, scripts, and fonts from the last hundred times you loaded it, so the load time you experience bears no relationship to what an actual new visitor gets on an average connection with nothing cached. Core Web Vitals, measured through Google PageSpeed Insights, look at this from the visitor's side: how quickly the main content becomes visible, how responsive the page feels when someone actually tries to interact with it, and how much the layout shifts around while things are still loading - the frustrating experience of trying to tap a button and having an image or ad load in above it and push everything down first. A page rated poor on any of these is losing visitors who never file a complaint, they simply leave and don't come back, and where field data is available this is measured against real user experience at scale, not just a synthetic lab test on your own machine.

Check what search engines and AI can actually see

Right-click and choose View Page Source, not Inspect Element - the two show different things, and the difference is the whole point. Inspect Element shows the fully rendered page after your browser has executed all the JavaScript, which is not what most crawlers see. View Page Source shows the raw HTML your server actually sent before any of that JavaScript ran, and that's much closer to what a search engine or AI assistant is working with. If your real content - headings, body paragraphs, prices, product details - only appears after JavaScript builds it client-side, and the raw HTML underneath is mostly empty divs and script tags, then crawlers with limited rendering budgets, and the simpler bots many AI assistants rely on, may never see your actual content at all. This is common and easy to miss on sites built as JavaScript applications without server-side rendering or prerendering, precisely because the site looks completely normal to the owner checking it in an ordinary browser tab.

Look at trust signals the way a first-timer does

None of these signals show up as a technical error, which is exactly why they're so often missed by anyone checking a site with tools rather than eyes. A first-time visitor has no relationship with your business yet and no way to independently verify anything, so they pattern-match instead, usually without realising they're doing it, against every scam or low-effort site they've encountered before - and those sites reliably share the same tells: no privacy policy, no visible ABN or physical presence, no reviews from real customers, stock photography that could belong to any business anywhere, and a contact form that gives no email address or phone number to fall back on if it doesn't work. Any one of these is a plausible reason for a cautious first-time visitor to quietly leave rather than risk it, and because the decision happens in seconds and is never voiced anywhere, these conversion killers never surface in a technical audit that only checks code.

Test that your forms actually deliver

Submit your own contact and enquiry forms, from a real device, and confirm the email or notification actually arrives - ideally more than once and from more than one browser. Contact forms fail silently more often than owners expect: a plugin update that quietly breaks the mail-sending configuration, a hosting change that alters how outbound mail is routed, a spam filter that starts eating notifications without complaint. The visitor's side of the form still shows a friendly thank-you message no matter what happened afterwards, so there's no visible symptom at all. A business can go weeks or months losing every enquiry a form generates without a single external error appearing anywhere, because the failure is invisible to everyone except the customer who never got a reply and quietly went elsewhere. Worth testing on a recurring schedule, not just once when the form was built, since the things that break it keep happening long after launch.

Then rank the findings by impact, not by count

A report listing sixty issues with no order attached is close to useless, because it puts a broken checkout button and a slightly-too-small heading in the same list with no way to tell which one is actually costing you money today. The right order starts with anything actively blocking a purchase or enquiry, since every day that stays broken is lost revenue happening right now, not a future risk. Next comes anything blocking search visibility, because if people can't find the site at all, nothing else you fix matters yet. Speed comes after that, since it affects how many of the visitors you do get actually stay long enough to convert. Polish and refinement come last, not because they don't matter, but because they only pay off once everything ahead of them in the queue has stopped bleeding visitors or revenue. The AuditHQ report applies this ordering automatically: every finding carries a severity rating, supporting evidence, and a recommended fix order across all nine areas it checks.

Frequently asked questions