Technical SEO Audit: What We Check and Why

Most SEO audits we've inherited from other agencies are 40-page PDF reports full of colour-coded charts and severity scores that tell you almost nothing about what's actually wrong. They flag 347 "issues," rank them by some arbitrary algorithm, and leave the business owner staring at a spreadsheet wondering which of those 347 things will actually move their search rankings. We've seen companies spend months chasing low-impact fixes because a report told them to, while the real problems sat untouched.

Our audits work differently. We focus on the things that prevent Google from finding, reading, and ranking your pages. That's a shorter list than most agencies want to admit, because a shorter list means fewer billable hours. But it's the honest list.

Crawlability: Can Google actually find your pages?

Before anything else matters, Google has to be able to reach your pages. If Googlebot can't crawl a URL, that URL doesn't exist in search results. Full stop.

We start every audit by running a full site crawl with Screaming Frog. It's not glamorous software. The interface looks like it was designed in 2008. But it does one thing better than anything else on the market: it crawls your site exactly the way a search engine would, and it shows you exactly what it finds. We typically crawl with a five-second delay between requests so we don't hammer the server, and we configure it to respect robots.txt the same way Googlebot does.

Here's what we're looking for in that first crawl:

Robots.txt blocking important pages. This sounds too basic to be a real problem, and yet we find it on roughly one in four sites we audit. A developer blocks a staging subdirectory during a rebuild. The site launches. Nobody removes the block. Six months later, the client wonders why their new service pages aren't ranking. We've seen entire blog directories blocked because a WordPress security plugin added an overly aggressive robots.txt rule that nobody reviewed.

Orphan pages. These are pages that exist on your server but have no internal links pointing to them. If no page on your site links to a URL, Googlebot has no way to discover it through crawling. It might still get indexed if it's in your sitemap, but Google assigns less value to pages it can only find through a sitemap rather than through your site's link structure. Screaming Frog's crawl comparison feature, where we cross-reference crawl results against your sitemap, catches these instantly.

Redirect chains. A page redirects to another page, which redirects to a third page, which finally redirects to the actual content. Each hop in that chain wastes crawl budget and dilutes the link equity flowing to the final URL. Google's own documentation says to avoid long redirect chains because they negatively affect crawling. We flag anything with more than one redirect hop and prioritise cleaning up chains that affect high-traffic pages.

Crawl budget waste. For sites under a few hundred pages, crawl budget isn't a concern. Google will crawl everything. But once you're above 10,000 URLs, crawl budget becomes real. Faceted navigation, session IDs in URLs, paginated archive pages with thin content, calendar widgets generating infinite date-based URLs -- these can create tens of thousands of crawlable URLs that add no search value. We check Google Search Console's crawl stats report to see how Googlebot is actually spending its time on your site, then compare that against what we want it to be crawling.

Indexation: Is Google keeping what it finds?

Getting crawled and getting indexed are two different things. Google crawls billions of pages and decides not to index a significant portion of them. According to Ahrefs' research on approximately 14 billion web pages, 96.55% get zero organic traffic from Google. Not all of those are indexation failures, but a meaningful number are pages that Google simply chose not to include in its index.

We pull the Index Coverage report from Google Search Console and look at the ratio of indexed pages to submitted pages. If you've submitted 500 URLs via your sitemap and only 300 are indexed, something is wrong. The report breaks down exactly why pages were excluded: crawled but not indexed, discovered but not crawled, blocked by robots.txt, duplicate content, soft 404s.

The ones that matter most:

"Crawled -- currently not indexed." Google saw the page, read it, and decided not to include it. This often means Google considers the content too thin, too similar to other pages on your site, or too low-quality to warrant a spot in the index. The fix isn't technical; it's content. But the audit identifies which pages are affected so you know where to focus.

Duplicate content signals. Canonical tags are supposed to tell Google which version of a page is the "real" one. When canonical tags are missing, point to the wrong URL, or conflict with other signals, Google makes its own decision about which version to index. We check every page's canonical tag against its actual URL. We also look for common duplication sources: www vs. non-www, HTTP vs. HTTPS, trailing slashes vs. no trailing slashes, and URL parameters creating alternate versions of the same page.

Noindex tags left behind. Similar to robots.txt blocking, we find stray noindex meta tags on live pages more often than we'd like. A staging environment uses noindex on everything, the site migrates to production, and the noindex tags come along for the ride. Google's December 2025 clarification made this worse: pages returning non-200 status codes may now be excluded from the rendering queue entirely, so any indexation issue compounds faster than it used to.

If Google can't crawl it, it doesn't exist. If Google crawls it but won't index it, you've got a content problem disguised as a technical one.

Site speed and Core Web Vitals

We've written a full breakdown of Core Web Vitals already, so we won't repeat all of it here. But speed is a fixed part of every technical audit because it affects everything else: crawl efficiency, indexation priority, user engagement signals, and conversion rates.

We test with PageSpeed Insights for field data from real Chrome users, then dig into specifics with Chrome DevTools and Screaming Frog's page speed tab. The metrics that matter most are LCP (Largest Contentful Paint), INP (Interaction to Next Paint, which replaced FID in March 2024), and CLS (Cumulative Layout Shift).

What we typically find on sites that haven't been audited:

Uncompressed images account for more LCP failures than any other single cause. A 3MB hero image served as a PNG when it should be a 180KB WebP. We see this constantly on WordPress sites using page builders, where the builder's media handling doesn't include any automatic compression.

Third-party scripts crushing INP scores. Analytics tags, chat widgets, cookie consent overlays, social proof popups -- each one adds JavaScript execution time to the main thread. We've audited sites where third-party code accounted for over 70% of total JavaScript execution. The fix is almost always removing things, not adding them.

Missing width and height attributes on images causing layout shift. The browser doesn't know how much space to reserve, so the page jumps around as images load. It's a five-minute fix per image and it can move CLS from failing to passing.

Studies show that even 100ms delays in interaction response can reduce conversion rates. A site that's slow to respond to taps and clicks doesn't just rank worse; it converts worse. For businesses in competitive Calgary markets, where a dozen competitors offer similar services, the faster site wins the customer who's comparison shopping.

Structured data and schema markup

Structured data doesn't directly boost rankings. Google has said this repeatedly. But it qualifies your pages for rich results -- those enhanced search listings with star ratings, FAQ dropdowns, event dates, business hours, and pricing. Nestle found that pages showing rich results had an 82% higher click-through rate than pages without them. Higher CTR from the same ranking position sends signals that can, over time, improve that ranking.

We audit structured data with both Google's Rich Results Test and the Schema Markup Validator. They check different things. The Rich Results Test tells you whether your markup qualifies for Google's specific rich result features. The Schema Markup Validator checks against the full schema.org specification and catches vocabulary errors the Rich Results Test might miss.

The issues we find most often:

JSON-LD syntax errors. A missing comma, a mismatched bracket, single quotes instead of double quotes. One wrong character and Google discards the entire block. No warning in your search results. No email notification. Just silence. We wrote about this pattern in depth in our schema markup mistakes guide.

Missing required properties. A LocalBusiness schema with a name and address but no image property. Technically valid, but not eligible for rich results. Google's documentation is specific about what's required per schema type, and "required" means "your rich result won't appear without this."

Wrong schema type. A dental practice marked up as a generic LocalBusiness instead of Dentist. A restaurant using LocalBusiness instead of Restaurant, missing out on properties like servesCuisine and acceptsReservations. Using the most specific type available gives Google more context and qualifies you for more detailed rich results.

Content that doesn't match the markup. Business hours in your schema that don't match what's visible on the page. An aggregate rating of 4.9 when your on-page reviews average 4.2. Google cross-references schema claims against page content. Mismatches can trigger a manual action that removes your rich results entirely. Our structured data guide for local businesses covers the full property requirements for each common schema type.

Internal linking: The most underrated ranking factor

Most businesses think of internal links as navigation. Menu links, footer links, sidebar widgets. Those are internal links, sure. But the ones that actually move rankings are contextual links -- links within your page content that point to other relevant pages on your site.

Google uses internal links to discover pages, understand topical relationships, and distribute authority across your site. A page with dozens of internal links pointing to it carries more weight than a page with two. Descriptive anchor text -- the clickable words in the link -- teaches Google what the target page is about. And click depth matters: if a page is more than three clicks from your homepage, Google may treat it as less important.

We use Screaming Frog's internal linking report and Ahrefs' Site Audit to map the full link graph of your site. What we're measuring:

Click depth distribution. How many clicks does it take to reach each page from the homepage? Anything beyond three clicks is a flag. We've audited sites where blog posts from two years ago were buried six clicks deep, behind archive pages and pagination, getting almost no organic traffic. Moving them to two clicks deep -- via contextual links from related, higher-authority pages -- noticeably increased their impressions within weeks.

Link equity concentration. Are most of your internal links pointing to the same five pages? Is your blog linking back to your service pages, or does content exist in isolation? We look at inlink counts per page and identify pages that should be receiving more internal links based on their commercial importance.

Anchor text patterns. If every internal link to your pricing page uses the anchor text "click here," you're wasting an opportunity to tell Google what that page is about. We audit anchor text distribution and recommend specific changes where generic text can be replaced with descriptive, keyword-relevant phrasing.

A study of over 5,000 websites found that 82% of potential internal linking opportunities are completely missed. That lines up with what we see. Most sites have a decent navigation structure but almost no contextual linking within their content. Two paragraphs about a topic that has its own dedicated page on the site, and no link between them.

If your site is going through a major rebuild or platform change, internal linking should be part of the migration plan from the start. Our website migration checklist includes link mapping as a required step for exactly this reason.

What actually moves the needle

After running hundreds of these audits over the past decade, we've developed strong opinions about what matters and what doesn't.

Fixing crawlability and indexation issues has the highest ceiling of any technical SEO work. If Google can't find or index your pages, nothing else you do matters. We've seen sites gain 30-40% more indexed pages within a month of cleaning up robots.txt blocks, orphan pages, and redirect chains. That's not a ranking improvement; that's pages entering the game that were previously sitting on the bench.

Site speed improvements have the most consistent return. Not because they dramatically change rankings overnight, but because they compound. Faster sites get crawled more efficiently, which means changes get indexed faster. Faster sites keep visitors longer, which improves engagement signals. Faster sites convert better, which means the traffic you already have produces more revenue.

Structured data is the quickest win for visibility, if not for rankings directly. Adding proper schema markup to a site that has none and seeing rich results appear within a few weeks is one of the most satisfying parts of this work. The ranking improvement is indirect and long-term, but the click-through rate improvement from rich results is immediate and measurable.

Internal linking is the most undervalued fix. It costs nothing. It requires no new technology. It's just the discipline of connecting your own content to itself in a way that makes sense for both readers and search engines. And yet it's the thing most sites neglect completely.

The audits that don't move the needle are the ones that spend 30 pages on meta description character counts and H1 tag duplication. Those matter at the margins. The sites that see real improvement are the ones that fix the structural issues first: make sure Google can find every page, make sure every page loads fast, make sure the important pages are connected to each other, and make sure the structured data is correct. Everything else is polish on top of that foundation.

If you're not sure where your site stands, we run technical SEO audits as part of our ongoing SEO and analytics work. And if you've already had an audit done by someone else and aren't sure what to do with the results, we're happy to look at it and tell you which items are worth your time.

Sources

• Crawl Budget Management -- Google Search Central -- Google's official documentation on crawl budget, crawl capacity limits, and managing large site crawling
• Google Crawling and Indexing Documentation -- Overview of how Google discovers, crawls, and indexes web pages
• Screaming Frog SEO Spider -- Official documentation for the site crawling tool used in our audit process
• Ahrefs Search Traffic Study: 96.55% of Pages Get No Traffic -- Research on approximately 14 billion pages showing the distribution of organic search traffic
• How to Complete a Technical SEO Audit in 8 Steps -- Ahrefs -- Ahrefs' guide to technical auditing with their Site Audit tool
• Intro to Structured Data Markup -- Google Search Central -- Google's official overview of structured data formats, including rich result CTR case studies (Nestle, Food Network, Rotten Tomatoes, Rakuten)
• web.dev Core Web Vitals -- Google's technical reference for LCP, INP, and CLS metrics and thresholds
• Google Search Central: Technical SEO Audit Methodology (November 2025) -- Martin Splitt's guidance on focusing audits on crawling and indexing issues rather than arbitrary scoring