Technical SEO

Most pages that fail in search never lost a ranking contest. They were never entered in one. Ivan Sp audits and fixes the technical faults that keep a well-written page from ranking at all. Content strategy and on-page writing assume Google can crawl, index, and trust the page it is reading. A technical fault breaks that assumption before any of the rest matters.

Why Technical Work Comes First

I order the work this way because the technical layer decides whether anything else is read at all. A page with a canonical tag pointing elsewhere will not rank, however well it is written. Neither will a page carrying a leftover noindex header, or one buried three clicks past where any crawler looks. Rewriting the copy on a page Google cannot find wastes the rewrite.

Technical audits therefore run before content work starts on an existing site, not after. Findings get sorted by what actually blocks visibility versus what only limits it. The two need different urgency.

Seven Areas This Practice Covers

Technical SEO touches everything between a page existing and a page being fairly evaluated:

Schema markup sits here as an audit and correction service, distinct from the generation work covered under schema markup automation for newly built pages.

Page Speed and Core Web Vitals

One distinction matters enough to state on this page directly, since it causes confusion often. Reading and explaining the Core Web Vitals scores Google already reports in Search Console is part of a technical audit. Fixing them is a different service, sitting outside every package. It usually needs hosting changes, template rebuilds, or platform-level work, and a developer with server access.

Where an audit finds speed is the limiting factor, that gets said plainly in the findings. The report names what kind of specialist the fix actually needs. The full boundary is set out on what this consultancy does not include.

What This Looks Like on a Monday Morning

Consider a marketing manager, six months into the role, opening a 400-item audit for the third time. The list is accurate and she still cannot tell anyone which item to start with.

She did not take this job to arbitrate between red flags on a spreadsheet. She took it to grow a channel, and the audit has quietly become the reason she cannot.

I sort that same list by how much traffic each fault is standing in front of. Five items rise and thirty-nine hundred move aside. Her next conversation with the director becomes a plan rather than an apology.

Where the Standard Technical Advice Breaks Down

The usual advice: Fix every error the audit tool reports, working down the list from red to amber to green.
What holds up in practice: Fix the errors that sit between a page and being evaluated at all, and ignore most of the rest. Audit tools rank by rule severity, and rule severity has almost no relationship to traffic exposure.

Picture a marketing manager handed a 400-item audit. The list opens with 180 missing meta descriptions in red, and the noindex tag on the entire services directory sits at item 214.

Three months later the meta descriptions are perfect and the services pages are still absent from Google. Nothing on the list was wrong, and the order was.

I reorder every finding by how much traffic it is standing in front of. A single inherited noindex tag outranks two hundred cosmetic warnings, whatever colour the tool painted it.

The cost of the wrong order is rarely the fix itself. The cost is the quarter spent believing the problem was being solved.

Four Things Commonly Assumed About Technical SEO

Which of these have you assumed on your own site?

I meet the same four assumptions on most first calls, and each one changes what the first month of work should be.

Commonly assumed	What actually holds
A site with no errors in an audit tool has no technical problem.	Audit tools check rules, not outcomes. A site can pass every rule and still have 300 pages Google declines to index.
Technical SEO is a one-time project that finishes.	Every template change, plugin update, and platform release can reintroduce a fault. The work is periodic rather than final.
Fixing more errors produces more traffic.	Most audit findings sit in front of no traffic at all. Impact comes from the small number of faults blocking commercially valuable pages.
A developer can handle it, since it is technical.	Most findings are decisions rather than code. Which URL should be canonical is a judgement about the business, not a programming task.
Slow pages are the most common technical problem.	Indexing and canonical faults are far more common and far cheaper to fix. Page speed engineering usually needs hosting and template changes.

Recognise two or three from the left-hand column and your next quarter of content budget is already at risk. The check below takes ten minutes and settles it.

What a Technical Audit Measures

Crawlability: Whether Googlebot can reach a URL at all, governed by robots.txt, status codes, and internal links.
Indexability: Whether a reachable URL is allowed into the index, governed by meta robots and the X-Robots-Tag header.
Canonicalisation: Which URL Google treats as the one worth indexing when several serve similar content.
Structured data: Whether machine-readable markup matches what the page visibly says.
Architecture: Click depth from the homepage, orphan pages, and how internal links distribute authority.
Crawl efficiency: Whether crawler requests reach useful URLs or drain into parameters and filters.
Primary evidence: Google Search Console, Bing Webmaster Tools, a full crawl, and raw server logs.

A Worked Example: Where the Traffic Actually Went

Consider a 900-page site that publishes steadily and sees flat organic traffic. The figures below are illustrative, chosen to show how a technical audit reorders priorities. They are not drawn from a client engagement.

Finding	Assumed cause	Actual cause in the audit
340 pages missing from Google	Thin content	Excluded by noindex tag inherited from a staging template
Category pages outranked by filters	Weak copy	Filter URLs self-canonicalising instead of pointing at the category
New posts indexed slowly	Low authority	Sitemap listing 404s, so the whole file was distrusted
Service pages buried	Not enough links	Click depth of 5 from the homepage

Ivan Sp runs the technical pass first because each row above would have absorbed a content budget and produced nothing. A rewrite cannot fix a noindex tag.

A technical audit works like an electrical inspection before a renovation. Nobody enjoys paying for it, and rewiring after the drywall goes up costs several times more.

How an Audit Runs

I start a technical audit with a full Screaming Frog crawl, cross-referenced against the Google Search Console Coverage report to confirm what Google itself has processed. Server-side headers get checked separately from the rendered HTML, since a noindex instruction can hide in either place independently.

Findings get grouped by root cause rather than by symptom. A single template fault, such as a missing self-referencing canonical tag, frequently explains dozens of individual page-level errors at once. Fixing the template resolves every page it touches in one pass.

How a Technical SEO Audit Runs

I work through a fixed sequence, because findings early in the list change the meaning of findings later in it.

Crawl the full site with Screaming Frog, configured to render JavaScript where the site depends on it.
Import the XML sitemap into the same crawl, so submitted URLs and linked URLs can be compared.
Export the Page Indexing report from Search Console, and group URLs by their exact status string.
Check every excluded URL for a meta robots tag and for an X-Robots-Tag header, since either can carry noindex.
Compare user-declared canonicals against Google-selected canonicals using the URL Inspection tool.
Measure click depth from the homepage, and list every page sitting deeper than three clicks.
Run the crawl analysis step to surface orphan pages present in the sitemap but linked from nowhere.
Validate structured data against the Rich Results Test, and confirm each claim also appears in visible copy.
Repeat the index checks in Bing Webmaster Tools, which reports faults Google’s tools do not surface.
Rank every finding by traffic exposure, then hand over a list ordered by impact rather than by severity label.

How a Technical Audit Is Scoped

I scope technical work against URL count and platform rather than against industry.

What arrives: A prioritised findings document, a crawl export, and the specific change required for each fault.
Typical duration: Two to four weeks for a site under ten thousand URLs.
What the client supplies: Search Console access, CMS access where fixes are implemented, and server or CDN logs where available.
Included: Diagnosis, prioritisation, implementation guidance, and verification that a fix took effect.
Not included: Page speed engineering, hosting changes, CMS migration, and template rebuilds.
What changes the estimate: Sites above roughly fifty thousand URLs, several subdomains, or a headless front end.
How it is quoted: After a short scoping call, once URL count and platform are known.

Tools and Primary Sources

Each source below defines behaviour the audit depends on, and each opens in a new tab.

Google Search Console reports the exact index status Google assigned to each known URL.
Screaming Frog SEO Spider crawls a site the way a search engine would and exports the result for comparison.
Bing Webmaster Tools crawls and indexes independently, so it surfaces faults Google’s reports omit.
Google Search Central documentation is the primary reference for crawling, indexing, and structured data behaviour.
Rich Results Test confirms whether Google can parse the structured data a page serves.

Three Checks You Can Run Today

I suggest three checks that need no tooling beyond a browser and Search Console.

Search Google for site: followed by your domain, and compare the rough result count against your page count.
Open the Page Indexing report in Search Console, and read the largest excluded group by name.
View source on your most important page, and search the markup for the word noindex.

A large gap between pages published and pages indexed is a technical signal, not a content signal. The excluded group’s exact status string usually names the cause.

Common Questions About Technical SEO

How long does a full technical audit take?

A site under 500 pages typically completes within one to two weeks, including the crawl, the Coverage report comparison, and a prioritized findings report. Larger sites run in stages, with the highest-value sections audited first.

Does every site need all seven areas addressed?

No. The initial crawl and Coverage comparison show which areas actually carry faults on a given site. The audit scopes to what the evidence supports, not to every check at full depth by default.

Can technical fixes be handed to my own developer?

Yes. Findings get delivered as a prioritized, specific list a developer can implement directly. Implementation support is available where a site has no in-house developer available.

Does technical SEO still matter on a small site?

Yes, though the faults differ. A small site rarely has a crawl budget problem. The usual causes are a canonical fault, an inherited noindex tag, or a sitemap listing URLs that no longer resolve.

Discuss a Technical SEO Audit

Technical audits get scoped after a first look at the site. The right depth depends on size and what the initial crawl already shows. The first call is a free 30-minute consultation with no pitch attached.

Book a free 30-minute consultation

Technical faults compound with weak content strategy, covered under content strategy and topical authority. They also compound with weak page structure, covered under on-page SEO for individual pages.