The technical SEO audit we run in the first hour

Most SEO conversations start with keywords. Ours starts with whether Google can actually crawl and index the site properly, because no amount of great content fixes a site that's technically capped. The first hour of any engagement is a fixed checklist, not exploratory poking around, and we run the same checklist on every new client regardless of industry or size.

This order matters more than it sounds like it should. Clients who've worked with content-first agencies before are often surprised we don't ask about keyword targets on the first call, and a little skeptical until they see what the technical audit actually turns up.

We pull the robots.txt file and check it isn't accidentally blocking sections of the site, a mistake we find on a surprising share of new client sites, usually left over from a staging environment configuration that never got reverted. We check the XML sitemap actually includes the pages that matter and excludes ones that shouldn't be indexed, and we run a crawl to find orphaned pages with no internal links pointing to them at all.

We also check crawl budget indirectly, by looking at how many low-value URLs, filtered category pages, tag archives, internal search results, are being generated and potentially competing for the same crawl attention as pages that actually matter. On a large enough site, this alone can meaningfully delay how quickly new, important content gets discovered and indexed.

A site claiming three hundred pages and Search Console showing ninety indexed is a real, common gap. We check for duplicate content issues, thin pages that add no value, and canonical tags pointing to the wrong URL, which is one of the most common silent causes of a page simply never showing up in results despite existing and being linked to internally.

The gap itself is diagnostic. A large gap concentrated in one content type, product pages, say, or a specific category, usually points to a templating issue rather than a hundred unrelated individual problems, which changes how we prioritize the fix.

We pull field data from Search Console rather than a single lab test, because that's the number that actually factors into ranking. A site failing Core Web Vitals thresholds for the majority of real visitors is competing with a real handicap against sites that pass, all else being equal.

We also segment this by device, since a site can pass comfortably on desktop and fail badly on mobile, and mobile is where the majority of search traffic actually lands for most of our clients. Reporting only the aggregate score hides exactly this kind of split.

We check what schema is already implemented and whether it validates cleanly, since broken schema is worse than no schema. We also run the mobile usability report specifically, since a meaningful share of search traffic for most of our clients is mobile, and a mobile-specific usability issue can suppress rankings for that segment even when desktop looks fine.

Broken schema in particular gets overlooked because it fails silently. A site can carry FAQ or Product markup that validated correctly at implementation and then quietly broke months later after a template change renamed a field or removed a component the schema depended on. Nobody notices because the page still renders fine to a human visitor; only the structured data test flags the actual problem, which is exactly why we run it fresh on every new engagement instead of trusting whatever the client's last agency reported.

Sites that have gone through a previous migration or two often accumulate redirect chains: URL A redirects to B, which redirects to C, which is the page that actually exists. Each hop adds latency and, beyond a couple of hops, can weaken how much ranking signal passes through. We flatten every chain we find down to a single direct redirect as part of the first-hour audit.

We've found chains four and five hops deep on sites that went through multiple platform changes over the years, each migration adding one more layer without anyone going back to clean up the earlier ones. Flattening these is quick, low-risk work with a real, if modest, upside.

Every issue gets logged with a severity rating and an estimated fix effort, and we fix crawlability and indexation issues before touching content strategy at all. Content built on top of a site Google can't fully crawl is optimizing the wrong variable first, and we'd rather delay the content calendar by a week than build it on a foundation with a known, fixable defect.

The severity rating matters because not every finding deserves the same urgency. A blocked section of the site in robots.txt gets fixed immediately, same day, because it's actively preventing indexation. A handful of redirect chains or a missing alt tag gets logged and scheduled but doesn't block anything else from moving forward. Sorting findings this way keeps the audit from turning into a wall of forty equally-weighted line items that overwhelms a client and obscures which three or four actually matter most.

Most clients come to us assuming their SEO problem is a content problem, because content is the visible, familiar part of SEO work. In our experience, a meaningful share of underperforming sites have at least one real technical issue actively suppressing rankings, and finding it in the first hour, rather than the third month, changes the entire trajectory of the engagement.

A client who's spent a year publishing content against a site with a genuine technical ceiling has effectively been optimizing a variable that was never going to move the outcome. Once the technical issue is fixed, the existing content often starts performing on its own within weeks, without a single new post being written, which is usually the moment a skeptical client becomes a genuine believer in doing the audit first rather than jumping straight to a content calendar.

A twelve-point technical audit handed over as a raw spreadsheet is easy for a non-technical stakeholder to skim past without absorbing what actually matters. We walk every new client through the findings live, in plain language, translating each technical issue into what it's actually costing them: pages that can't be found, rankings that are artificially capped, traffic that's being sent to the wrong result. That framing is what turns a checklist into a shared priority list both sides actually act on.