How do I fix technical SEO issues?

Run any technical SEO tool and it will hand you several hundred issues. Perhaps four of them are costing you traffic. The skill is not in fixing issues — it is in knowing which ones are real.

Three severity tiers

Every technical finding belongs in one of three tiers, and the tier determines whether it gets fixed this week, this quarter, or never.

The failure mode is inverted priority: teams fix the cosmetic tier because it is easy and the counter goes down, while a blocking issue quietly removes a third of the site from the index.

Blocking issues

Six problems belong here. Any one of them can erase a section of a site.

Accidental noindex. A noindex shipped in a template, a CMS setting, or an HTTP header. This is the single most damaging technical mistake in SEO because it is silent — nothing errors, pages simply stop existing in search. Fix: crawl the whole site for noindex directives and check the HTTP headers as well as the HTML, since X-Robots-Tag is easy to miss entirely.

Robots.txt disallow. Usually a staging rule that survived launch. Fix: read the file line by line rather than relying on a tool summary, and test your key URLs against it explicitly.

Server errors under crawl load. A site that returns 200 in a browser and 5xx when a crawler requests fifty pages a minute. Fix: check the crawl stats report in Search Console for error spikes; if they correlate with crawl rate, the problem is capacity rather than configuration.

Wrong canonical tags. A canonical pointing at the homepage from every page, or at a parameterised duplicate, tells Google to ignore the page entirely. Fix: confirm every canonical is self-referencing unless you deliberately intend otherwise.

Redirect chains and loops. More than two hops and crawlers frequently give up. Fix: point every redirect at the final destination directly rather than daisy-chaining through history.

Blocked AI crawlers. Covered in its own section below, because it is now the most commonly overlooked blocking issue.

Suppressing issues

These do not remove pages from search; they hold back pages that are otherwise working. Schedule them by the traffic at stake rather than by how many instances the tool counted.

Duplicate and near-duplicate content. Several pages competing for one query split the signal so none accumulates enough to rank. Fix: consolidate into the strongest page and redirect the rest. Sites gain positions from deletion regularly, which remains the most counterintuitive reliable result in the discipline.

Broken internal links. Dead-end links waste crawl budget and strand authority. Fix: a crawler finds these in minutes; repointing them is mechanical.

Orphaned pages. Live URLs with no internal links pointing at them. Search engines struggle to find them and readers never will. Fix: compare a crawl against your sitemap; anything in the sitemap but not in the crawl is orphaned.

Slow pages. Real but modest for ranking, and more consequential than it looks for AI crawlers, which use tight timeouts. Fix: address the worst offenders, ignore the pursuit of perfect scores.

Thin internal linking on important pages. Your best pages should be linked from your other strong pages with descriptive anchor text. This is free, entirely under your control, and consistently underused.

Cosmetic issues

Real findings, genuinely no measurable ranking effect. Log them so nobody re-discovers them next quarter and treats them as urgent.

• Meta descriptions slightly over or under a character count.
• Heading levels skipping a step for visual reasons.
• Missing alt text on decorative images. (Missing alt on meaningful images is an accessibility issue and belongs in the suppressing tier for reasons unrelated to ranking.)
• Perfect scores on synthetic performance metrics.
• URL length, trailing slashes, and other consistency preferences with no functional effect.
• Low text-to-HTML ratio, which is not a ranking factor and never was.

The new blocking tier: AI retrievability

Two issues belong in the blocking tier that almost no technical SEO tool reports, because the tools predate them.

Content that only exists after JavaScript. Googlebot renders JavaScript in a headless Chrome engine. AI crawlers do not. An analysis by Vercel and MERJ covering more than 500 million GPTBot fetches recorded zero JavaScript execution — it downloaded JavaScript files roughly 11.5% of the time and never ran them — with the same behaviour observed for ClaudeBot and PerplexityBot. They fetch raw HTML under tight timeouts, take what is there, and move on.

A client-side-rendered page can rank perfectly well in Google and be entirely invisible to ChatGPT.

Fix: disable JavaScript in your browser and load your ten most important pages. If the answer text is not there, move that content to server-rendered HTML. This is a five-minute check and it is the highest-severity finding available on most modern sites.

AI crawlers blocked at the CDN. Many platforms ship bot-management presets that deny AI user agents by default, so the block is inherited rather than chosen. It does not appear in robots.txt and most audits never look. Fix: check your CDN or WAF settings explicitly, decide deliberately which crawlers to allow, and verify from outside your own network.

Verifying a fix actually landed

More technical fixes fail at verification than at implementation. Three steps prevent it.

Confirm the change is in the served HTML. Not in the CMS, not in staging — fetch the live URL and look. Caching layers routinely serve the old version for hours or days after a deploy, and a great many “the fix did not work” conclusions are actually cache.

Request a fresh crawl for a handful of URLs. URL Inspection in Search Console gives you a live test and a recrawl request. This works for a few pages; at scale, rely on internal linking and sitemap freshness instead.

Then wait, and change nothing else. Reassessment takes days to weeks. If you change the content, the links and the schema while waiting, you lose the ability to attribute any outcome — which matters enormously when the same fix has to be applied to another four hundred pages.

A triage worksheet

When a tool hands you a report, run each finding through four questions before it earns a place on the roadmap.

1. Does this prevent a page being reached, stored or rendered? If yes, it is blocking. Stop reading and fix it.
2. Can I name the pages affected and their traffic? If not, the finding cannot be prioritised. A count of instances is not an impact estimate.
3. Would fixing this change what a user or a crawler experiences? If the honest answer is no, it is cosmetic regardless of how the tool colour-coded it.
4. What specifically changes, and who changes it? A finding without a named change and a named owner is a complaint.

Findings that survive all four go on the roadmap ranked by traffic at stake. Everything else goes in a log. The log matters: without it, the same cosmetic findings get re-discovered every quarter and re-argued from scratch.

What to do when a fix has no effect

You ship a change, wait a month, and nothing moves. Three possibilities, in order of likelihood.

The issue was cosmetic and you misjudged the tier. The most likely explanation, and worth accepting quickly rather than looking for a second cause. A finding that produced no change was, by definition, not what was holding the page back.

It was real but not the binding constraint. Fixing a redirect chain on a page that is not ranking because of content depth is a genuine improvement that changes nothing measurable. Both things can be true.

It has not been reassessed yet. Low-traffic pages can go many weeks between crawls. Check the last crawl date in URL Inspection before concluding anything.

The rollback question

Before shipping any technical SEO change at scale, answer one question: how would we detect and reverse this if it is wrong?

Technical fixes fail in a distinctive way — silently, across thousands of pages, with a lag of weeks before the damage appears in Search Console. A canonical rewrite applied site-wide can deindex a section, and by the time traffic reflects it the deploy is three sprints back and nobody connects the two.

Two habits prevent most of this. Ship to a subset first where the change is risky and reversible — one template, one section — and compare against the untouched remainder. Record what changed and when in a dated log alongside your analytics, so that when something moves in six weeks you can look up what happened rather than reconstructing it from memory and commit messages.

One last discipline: after fixing anything in the blocking tier, re-run the check thirty days later. Blocking issues have a habit of returning with the next deploy, and a noindex that comes back is exactly as damaging as the one that started it.

Sources

• Vercel and MERJ — analysis of 500M+ GPTBot fetches finding zero JavaScript execution; GPTBot downloaded JS files ~11.5% of the time without running them; same behaviour for ClaudeBot and PerplexityBot.
• Google Search Central — documentation on robots meta directives, the X-Robots-Tag header, canonicalisation and crawl stats.

Frequently asked questions