The short version: before you touch page speed scores or schema markup, check whether Google can find, crawl, and index your pages, because that’s the layer that breaks silently and costs the most traffic. Indexability, then crawlability, then mobile rendering, then Core Web Vitals, then everything else. Most technical SEO audits I’ve seen get this order backwards and spend three weeks on things that were never the problem.
Why the order matters more than the checklist
Every technical SEO checklist you’ll find online has roughly the same 40 to 60 items on it. Schema markup, alt text, canonical tags, XML sitemaps, hreflang, page speed, HTTPS, structured data, internal linking, breadcrumbs. All valid. All worth checking eventually. But if you run through them in the order most templates present them (usually alphabetical, or by category), you’ll burn hours polishing things that were never causing the problem, while the actual issue sits three sections down the list.
I run audits for clients as part of my AI and marketing consulting work, and the pattern is almost always the same. Someone hires an agency, gets a 40-page PDF with a colour-coded traffic light system, and 90% of the red flags are cosmetic. Missing alt text on old blog images. Meta descriptions that are 12 characters too long. Meanwhile the site has 4,000 pages Google has never indexed because a developer left a disallow rule in robots.txt after a staging site migration eight months ago. Nobody caught it because nobody checked crawlability first.
Step 1: check whether Google can find and index your pages at all
This is the one people skip because it feels too basic to be the problem. It’s almost never too basic to be the problem.
- Open Google Search Console and go to the Pages report under Indexing. Look at the ratio between “indexed” and “not indexed.” If more than 20% of your important pages are in the not-indexed bucket, stop everything else and find out why.
- Check the specific reason Google gives for excluded pages. “Crawled, currently not indexed” usually means thin or duplicate content. “Discovered, currently not indexed” often means crawl budget issues on larger sites. “Excluded by noindex tag” means someone told Google not to index it, sometimes on purpose, sometimes by accident during a CMS migration.
- Check robots.txt directly at yoursite.com/robots.txt. I’ve found disallow rules blocking entire folders left over from a staging environment more times than I can count. It takes 30 seconds to check and can be the entire fix.
- Search site:yourdomain.com in Google and scroll through what comes up. If pages you care about aren’t there, or pages you didn’t expect are, that tells you something a checklist won’t.
The client story that made me change my own process
A client came to me two years ago with organic traffic that had dropped from around 40,000 sessions a month to 11,000 over five months. Their previous agency had spent that entire time optimising meta titles and adding FAQ schema. The actual cause: a site migration to a new CMS had generated parameter-based duplicate URLs (things like /product?colour=red and /product?colour=red&size=m for the same page), and none of them had canonical tags pointing back to the original. Google was crawling and half-indexing thousands of near-duplicate pages, and the real pages were getting starved of crawl budget as a result.
We fixed it with canonical tags on every parameterised URL, a robots.txt update to block the worst offenders, and a resubmitted sitemap with only the real URLs listed. Traffic recovered by roughly 34% within 11 weeks, without touching a single meta description. That’s the whole point of checking indexability first: it’s the layer where small mistakes cause the biggest damage, and it’s invisible unless you go looking.
Step 2: check crawlability, not just indexability
Indexed and crawlable aren’t the same thing, and this distinction trips people up constantly. A page can be indexed from months ago but no longer crawlable because something changed since.
- Run a crawl with Screaming Frog (the free version handles up to 500 URLs, which covers most small business sites) and check for orphan pages, broken internal links, and redirect chains longer than one hop.
- Check your XML sitemap matches what’s live. I’ve seen sitemaps still listing pages deleted a year earlier, and sitemaps missing entire new sections of a site because nobody updated the sitemap generator settings after a redesign.
- Look at your crawl stats in Search Console under Settings. If Googlebot’s crawl requests have dropped sharply with no obvious reason, that’s worth investigating before anything cosmetic.
Step 3: check mobile rendering, not just “mobile-friendly”
Google has used mobile-first indexing for every site since 2023, meaning the mobile version of your page is the version that gets crawled and ranked, full stop. Not a variant. The primary version.
The check here isn’t just “does the Mobile-Friendly Test pass.” It’s whether the content on mobile matches the content on desktop. I’ve found sites where the mobile theme hides entire sections of text behind accordions that never load their content on certain devices, or where a mobile menu blocks half the visible content above the fold. Google is indexing what mobile users see, so if your best content is desktop-only, it’s functionally invisible to the algorithm now.
Use Chrome’s device toolbar (F12, then the phone icon) and scroll through your key pages on a simulated mobile view. Five minutes will tell you more than a scanner report.
Step 4: HTTPS, redirects, and canonical consistency
Quick checks, but ones people assume are fine and never verify:
- Does your site redirect http to https everywhere, or only on the homepage? Check a few inner pages directly.
- Does www redirect to non-www (or vice versa) consistently, with one canonical version chosen and enforced?
- Are there redirect chains, where A redirects to B which redirects to C? Each hop loses a small amount of authority and adds load time. Screaming Frog’s redirect chain report will show these in one pass.
- Does every page have a self-referencing canonical tag, or a canonical pointing to the correct version? This one connects directly back to the duplicate content problem from Step 1.
Step 5: Core Web Vitals and page speed (yes, after all of this)
Here’s the uncomfortable bit that most technical SEO articles won’t say plainly: Core Web Vitals are a minor ranking factor compared to how much attention they get. Google’s own John Mueller has said as much in various forums over the years, that page experience signals act more as a tiebreaker than a primary ranking factor. Agencies love talking about Core Web Vitals because it produces impressive-looking scores and dashboards, and because it’s a service that’s easy to sell. But I’ve watched clients spend thousands improving Largest Contentful Paint from 3.2 seconds to 1.8 seconds and see no measurable ranking change, because their real problem was still sitting in indexation.
That doesn’t mean skip it. Slow, janky pages hurt conversion rate and user trust regardless of what Google does with the score. Check it, just don’t check it first, and don’t expect it to fix a ranking problem caused by something else entirely.
Run your key pages through PageSpeed Insights and look at Cumulative Layout Shift specifically, since it’s the metric most commonly caused by something fixable in ten minutes: images and embeds without set dimensions. This comes up constantly with embedded video and social content. If you’re embedding Instagram Reels or Stories in blog posts (a lot of my clients do, for engagement and social proof), an embed with the wrong frame size or an unset aspect ratio will reserve the wrong amount of space on the page, and when the actual embed loads a beat later, everything below it jumps. That single jump can push your CLS score into the red on an otherwise fast page. Getting the size ratio right before you embed anything solves it before it becomes a scanner flag.
Step 6: structured data, but only where it changes what shows in search
Schema markup gets checked far too early in most audits, given how narrow its actual impact is. It doesn’t help you rank higher on its own. What it does is control whether you get rich results, star ratings, FAQ dropdowns, breadcrumb trails in the SERP, that kind of visual real estate.
Check it with Google’s Rich Results Test, but only after Steps 1 through 5 are clean. Adding FAQ schema to a page that isn’t indexed changes nothing.
Step 7: internal linking and orphan pages
Last on this list, first thing people forget about. Run your crawl report again and look specifically for pages with zero internal links pointing to them. Those are orphan pages, and even if they’re indexed, they’re getting almost no authority passed through your site’s internal structure. I keep an internal linking pass as a standing quarterly task now, because content sections grow and old posts stop getting linked to as newer ones take over the homepage and navigation. A guide I wrote a while back on work from home jobs to consider first sat with almost no internal links for months after publishing simply because I forgot to go back and add it into older, related posts. Fixed it, saw a slow but steady lift in its own rankings over the following quarter.
What I’d tell someone starting from zero
If you only have an hour, spend it on Search Console’s Pages report and robots.txt. If you have a full day, add a Screaming Frog crawl and a mobile rendering check on your top ten pages by traffic. Everything past that, Core Web Vitals, schema, deeper redirect audits, is worth doing, but it’s optimisation on top of a foundation, not the foundation itself. Getting this order backwards is the single most common mistake I see, and it’s the reason businesses pay for technical SEO work and see nothing change.
If you’re not confident running any of this yourself, it’s a fair thing to bring in outside help for, and it’s worth understanding what that involves and what it should cost before you sign anything.
Frequently asked questions
What’s the very first thing to check in a technical SEO audit?
Check Google Search Console’s Pages report to see what percentage of your site is indexed, then check robots.txt directly. Indexability problems cause the biggest traffic losses and are the most commonly overlooked, because they’re invisible unless you go looking for them.
Do Core Web Vitals affect rankings?
They’re a minor ranking factor, closer to a tiebreaker than a primary signal, according to Google’s own public statements. They matter for user experience and conversion rate regardless, but fixing indexation and crawlability issues first will move rankings more than shaving a second off load time.
How often should I run a technical SEO check?
A full audit once a quarter is reasonable for most small business sites. Check Search Console’s Pages and Coverage reports monthly at minimum, since indexing problems from a CMS update or plugin change can appear within weeks and quietly erase months of traffic before anyone notices.
Can I do a technical SEO audit myself without hiring someone?
Yes, for most small business sites. Google Search Console is free, Screaming Frog’s free tier covers up to 500 URLs, and PageSpeed Insights is free. The steps above cover roughly 80% of what a paid audit would find. Larger or more complex sites, especially ones with international versions or heavy JavaScript rendering, tend to benefit more from bringing in someone experienced.
If you want your own guide on this published here, you can write for us about web design.
