A technical SEO audit reviews whether search engines can crawl your pages, index the right ones, render what’s on them and load them quickly enough to rank. At #10 we run the checks in that order, because each stage depends on the one before it: there is no point tuning structured data on a page Google can’t reach or has chosen not to index. The order matters more than the length of the checklist, and it’s what separates a useful audit from a list of technical issues.
Plenty of audits are really tool exports. A site audit tool lists hundreds of technical SEO issues sorted by count, so a missing alt attribute sits next to a robots.txt rule that blocks every product page, and both get the same red icon. The fix list that comes out of a good technical audit is short, ranked by what it costs you, and written so a developer can act on it without a second meeting.
This guide covers the website’s technical aspects only. If you need the whole picture (content, on-page SEO, links, local and AI search visibility), start with our SEO audit checklist and come back here for the technical depth.
Why order matters in a technical SEO audit
Search engines work through a sequence. A crawler discovers a URL and requests it. The search engine decides whether the page is worth keeping in its index. It renders the page to see the content, including anything JavaScript adds. Only then does the page compete for rankings, which is where relevance and speed come into play.
<figure class=“ar-fig”><svg viewBox=“0 0 640 250” role=“img” aria-labelledby=“tsa-order-t tsa-order-d”><title id=“tsa-order-t”>The order of a technical SEO audit</title><desc id=“tsa-order-d”>Four stages left to right: crawl, index, render, rank. A failure at any stage blocks every stage after it.</desc>
<g font-size=“20” font-weight=“700” text-anchor=“middle”>
<rect x=“8” y=“40” width=“134” height=“80” rx=“12” fill=“none” stroke=“var(–ar-c1)” stroke-width=“3”/><text x=“75” y=“88” style=“font-size:20px”>Crawl</text>
<rect x=“170” y=“40” width=“134” height=“80” rx=“12” fill=“none” stroke=“var(–ar-c1)” stroke-width=“3”/><text x=“237” y=“88” style=“font-size:20px”>Index</text>
<rect x=“332” y=“40” width=“134” height=“80” rx=“12” fill=“none” stroke=“var(–ar-c2)” stroke-width=“3”/><text x=“399” y=“88” style=“font-size:20px”>Render</text>
<rect x=“494” y=“40” width=“138” height=“80” rx=“12” fill=“var(–ar-c1)” fill-opacity=“.12” stroke=“var(–ar-c1)” stroke-width=“3”/><text x=“563” y=“88” style=“font-size:20px”>Rank</text>
</g>
<g stroke=“var(–ink)” stroke-width=“2.5” fill=“none”><path d=“M144 80h22M158 72l8 8-8 8”/><path d=“M306 80h22M320 72l8 8-8 8”/><path d=“M468 80h22M482 72l8 8-8 8”/></g>
<g text-anchor=“middle” fill=“var(–muted)”><text x=“75” y=“150” style=“font-size:15px;fill:var(–muted)”>robots, errors</text><text x=“237” y=“150” style=“font-size:15px;fill:var(–muted)”>noindex,</text><text x=“237” y=“170” style=“font-size:15px;fill:var(–muted)”>canonicals</text><text x=“399” y=“150” style=“font-size:15px;fill:var(–muted)”>JavaScript</text><text x=“563” y=“150” style=“font-size:15px;fill:var(–muted)”>speed, schema,</text><text x=“563” y=“170” style=“font-size:15px;fill:var(–muted)”>redirects</text></g>
<path d=“M8 210h624” stroke=“var(–line)” stroke-width=“1.5”/><text x=“8” y=“238” style=“font-size:15px;fill:var(–ink)”>A failure at any stage blocks every stage to its right.</text>
</svg><figcaption>The order we audit in. Crawl and index problems come first because they make every later fix pointless for the pages they affect.</figcaption></figure>
Fixing out of order wastes money. Weeks spent shaving load time off collection pages are wasted if a canonical tag has told Google to index a different URL instead. The speed work is real, but it can’t help a page that isn’t eligible to appear.
So when we conduct a technical SEO audit, it runs in six passes. The first three follow the diagram. The last three (redirects and internal links, site speed, structured data) decide how well indexed pages compete.
| Pass | Where we look first | What a problem looks like |
|---|---|---|
| 1. Crawl access | robots.txt, server logs, Crawl stats report | Important sections blocked, 5xx errors, crawl traps |
| 2. Indexing | Page indexing report, URL Inspection | Good pages excluded, junk pages indexed |
| 3. Rendering | Rendered HTML in URL Inspection | Main content or links missing until scripts run |
| 4. Redirects and links | A full site crawl | Chains, temporary redirects, orphan pages |
| 5. Site speed | Core Web Vitals field data | Slow templates on phones, heavy third-party scripts |
| 6. Structured data | Rich Results Test, Search Console enhancements | Invalid or misleading markup |
That table is our technical SEO audit checklist in short form, and it’s the same sequence whether we perform a technical SEO audit on a 50-page brochure site or a large catalog. If you want to audit your site yourself, work down it in order and resist the urge to skip to the pass you find most interesting.
Pass 1: can search engines crawl the site?
Crawling is the search engine fetching your URLs. If that fails, nothing else in the audit matters for the affected pages. We crawl your website ourselves with a desktop crawler, a tool like Screaming Frog or Sitebulb, so we can see the same URLs and status codes a search engine would.
We start with robots.txt, the plain text file at the root of the domain that tells crawlers which paths to skip. One overbroad rule can block a whole product directory. We read it line by line rather than trusting a tool’s summary, then test a sample of important URLs against it.
Next come server responses. Google Search Console’s Crawl stats report shows how many requests Googlebot made, how fast the server answered and how many responses were errors. A rising share of 5xx errors (the server failed) or timeouts tells Google to slow down, and on a large catalog that means new and updated pages get picked up late.
Then we look for crawl traps: URL patterns that generate near-infinite variations. On Shopify, filtered and sorted collection URLs can multiply quickly. On WordPress, tag and date archives do the same, and so can calendar plugins. A crawler spending its time on ten thousand filter combinations isn’t spending it on your new products.
Last in this pass is the XML sitemap, the file that lists the URLs you want indexed. It should contain only live, indexable, canonical URLs that return a 200 status. A sitemap full of redirects and noindexed pages sends mixed signals and makes the Page indexing report harder to read.
Pass 2: are the right pages indexed?
Being crawled doesn’t mean being indexed. Google decides which pages to keep, and the Page indexing report in Search Console tells you what it decided and why.
We look at this from both directions. First, are important pages missing? Common causes are a stray noindex tag, a canonical tag pointing to a different URL, or Google judging the page a duplicate of something else. “Crawled, currently not indexed” on product or category pages is worth investigating page by page with the URL Inspection tool.
Second, is junk getting in? Staging copies, internal search results, thin tag pages and parameter variants all dilute the site. On WordPress, attachment pages (a page for every uploaded image) are a classic example. They’re harmless one at a time and a problem by the thousand.
Canonical tags deserve their own check. A canonical tag tells search engines which URL is the main version of a page when several URLs show the same content. Shopify, for example, can show a product at a collection-scoped URL as well as its main product URL, and the theme’s canonical tag is what keeps those from competing. Custom themes and apps sometimes break that. We check canonicals by template (product, collection, article, page) rather than by sampling random URLs, because a template bug repeats on every page that uses it.
Duplicate content inside the site is often a symptom of structure rather than writing. For an industrial LED distributor we work with, two pages had grown up targeting the same buyer question. We resolved the cannibalization by redirecting the weaker URL into the more complete article and correcting internal links across more than 40 pages, so the site’s own links stopped pointing at the old address.
Pass 3: can search engines render what visitors see?
Rendering is the step where a search engine runs the page’s code and sees the finished result. Google renders JavaScript, but rendering is deferred and can fail, and other crawlers (including many AI crawlers) often don’t run JavaScript at all.
The check is simple to describe. Open URL Inspection in Search Console, test the live URL and compare the rendered HTML with what a visitor sees. Then fetch the raw HTML without JavaScript and compare again. We’re looking for main content, product details, prices, reviews and internal links that only appear after scripts run.
Common problems on the platforms we work on:
- Page builders and apps that inject product descriptions, FAQs or review text with JavaScript after the page loads.
- Navigation menus or “load more” buttons that create links only when clicked, so crawlers never find deeper pages.
- Tabs and accordions whose content is fetched on demand rather than included in the page.
- Lazy-loaded images and sections that never load for a crawler that doesn’t scroll.
If important content only exists after rendering, the fix is usually to output it in the server-rendered HTML. That’s a theme or template change, which is why this pass often produces the most developer tickets.
Pass 4: redirects, internal links and site structure
With access, indexing and rendering confirmed, we turn to how the site’s own structure helps or hurts the pages that are indexed.
Redirects. A 301 is a permanent redirect and tells search engines to transfer the old URL’s standing to the new one. A 302 is temporary and tells them the old URL will come back. When we audited the previous store of a premium California olive oil and wine brand, we found more than a hundred 302 redirects that should have been 301s, alongside duplicate title tags and missing breadcrumb markup. That kind of finding is common after years of manual changes. We also look for redirect chains (A to B to C) and loops, and for redirects that send old product URLs to the homepage instead of the closest equivalent.
Internal links. Links between your own pages tell search engines which pages matter and how they relate. We look for orphan pages (indexable pages with no internal links), important pages buried many clicks from the homepage, and internal links that point at redirected or broken URLs. Fixing internal links to point straight at the final URL is cheap and removes a hop every crawler would otherwise take.
Structure. Category hierarchy is a technical decision as much as a merchandising one. For the LED distributor, category restructuring and 301 maintenance at scale have been part of the work for years, because a technical catalog keeps adding product lines and retiring part numbers. Every retired URL needs a destination decision.
If you’re planning a platform move, this pass becomes the redirect map. We cover what typically breaks in what gets lost in a Shopify migration.
Pass 5: site speed and Core Web Vitals
Site speed matters for rankings and matters more for user experience. Google’s Core Web Vitals measure three things: how fast the main content appears (Largest Contentful Paint, or LCP), how quickly the page responds to a tap or click (Interaction to Next Paint, or INP) and how much the layout jumps around while loading (Cumulative Layout Shift, or CLS). INP replaced the older First Input Delay metric in 2024, so a technical SEO site audit from a few years ago may be measuring the wrong thing in 2026.
Page speed is also where generic SEO best practices cause the most wasted effort. Two habits make this pass useful rather than noisy. First, we read field data (measurements from real visitors, shown in Search Console’s Core Web Vitals report) before lab tests like a single Lighthouse run. Lab tests are good for diagnosing a cause and poor at telling you what customers experience. Second, we audit by template. If the product template is slow, every product page is slow, and one fix covers all of them.
On ecommerce sites, third-party scripts are usually the biggest cost. Review widgets and chat tools add up, and uninstalled apps often leave their code behind. On the olive oil brand’s Shopify Plus store, recent work included deferring scripts a third-party app loaded on every page and preloading the homepage hero image so the largest element could start downloading sooner. Neither is a rewrite. Both came from measuring which resources were blocking the first meaningful paint.
If speed turns out to be the main problem, it’s often worth scoping as its own project. Our site speed optimization service covers the measurement and fixes in more detail.
Pass 6: structured data
Structured data, often called schema markup, is code (usually JSON-LD) written to help search engines understand what a page is about in a machine-readable way: this is a product, this is its price, this is the brand, this is the breadcrumb path. It can make pages eligible for richer search results, and it gives AI systems clean facts to work with. Of all the technical elements in this audit, it’s the one most often added by apps without anyone checking the result.
We check four things:
- Validity. Does the markup parse without errors? Google’s Rich Results Test and the enhancement reports in Search Console show this.
- Coverage by template. Product pages should carry Product markup with offers and availability; articles should carry Article markup; the site should describe the organization once, consistently. BreadcrumbList helps on deep catalogs.
- Accuracy. Markup has to match what’s visible on the page. A price, rating or availability in the schema that differs from the page is a problem, and Google can treat misleading markup as spam.
- Duplication. Shopify themes and apps often each add their own Product markup, so a single page ends up with two conflicting versions. We pick one source and remove the other.
For the LED distributor, we added FAQPage and TechArticle markup as part of retrofitting technical content with citable lead paragraphs and spec tables. Markup helps a page describe itself. It doesn’t replace the content it describes.
What a useful audit report looks like
A technical SEO audit is only as good as the fix list it produces. Many tools roll everything into a single SEO health score, which is fine for tracking but says nothing about what to fix first. Ours has the same shape every time: each issue gets a priority, the affected template or URL pattern, why it matters in a sentence, the change to make, and an owner. Nothing the audit uncovers is buried in a 90-page export, and nothing goes on the list without a reason tied to overall SEO performance.
That’s where a technical SEO audit helps most: it turns a pile of findings into an order of work. Priority comes from two questions. How many important pages does this affect? And does it stop pages from being crawled or indexed, or does it only make them compete less well? A noindex tag on a product template outranks a hundred missing alt attributes every time, because one costs organic traffic on every keyword those pages could rank for and the other mostly doesn’t.
We also re-check before calling anything fixed. For the LED distributor, a DataForSEO on-page audit runs as a gate before new content publishes, which catches the most common technical regressions before they reach the live site rather than after the next crawl.
You can see a first pass of these checks for any public page in our instant site audit. It reads one page the way a crawler does and picks the three fixes we’d make first. It can’t see your server logs, Search Console data or the rest of the site, which is what a full audit covers.
Questions people ask about a technical SEO audit
What does a technical SEO audit include?
The six passes above: crawl access, indexing, rendering, redirects and internal links, page speed, and structured data, followed by a ranked fix list and a walkthrough. Content quality, links from other sites and keyword targeting belong to the wider audit, though we flag anything technical that affects SEO ranking on those pages.
How long does a technical SEO audit take?
For most Shopify and WordPress sites, two to three weeks from access to walkthrough. Large catalogs, multiple languages or several storefronts take longer, mostly because there are more templates and URL patterns to check.
What SEO audit tools do you use?
Google Search Console first, because it’s Google’s own view of your site. Then a full site crawler, the URL Inspection and Rich Results tools, Core Web Vitals field data, and server logs where we can get them. SEO tools collect the data. Deciding what matters is the part a tool can’t do, and it’s where experienced SEO professionals earn their fee.
Is a free SEO audit enough?
A free SEO checker is a good smoke test, and free tools like Lighthouse and the Rich Results Test are part of our own kit. It catches missing titles, broken canonicals and slow pages on the URL you give it. It can’t tell you which of your 5,000 pages Google has excluded or why, and it doesn’t rank findings by what they cost you.
Should we run a technical SEO audit before a redesign or migration?
Yes, ideally before the new site is built. The audit tells you which URLs carry search traffic, which redirects already exist and which template problems not to repeat. It’s much cheaper to fix a redirect plan before launch than after.
Do you fix the problems as well?
We can. Some clients hand the fix list to their own developers, and the list is written so they can. Others have us make the changes on their Shopify or WordPress site, and we re-check each fix after it ships.
Where to start
If traffic has stalled, a migration is coming, or nobody has looked under the hood in a year, a technical site audit is the right first step. Every other part of an SEO strategy (content, off-page SEO and links, AI visibility) sits on that technical foundation, and technical optimization is usually the fastest of them to pay back. Run the instant site audit on your most important page to see the kind of issues it surfaces, then look at our technical SEO audit services for what the full website audit includes. If the technical layer is only part of the question, our SEO programs cover the ongoing work, and you can always talk to #10 about where your site stands.
