Run any audit tool and it will hand you four hundred warnings. Perhaps six of them affect what you rank for. This is how to tell the difference, and what to fix first.
Key takeaways
- Only three technical faults reliably cost rankings: pages the crawler cannot reach, pages it cannot render, and duplicate versions competing with each other.
- Core Web Vitals are a tiebreaker, not a ranking lever. A fast page about the wrong topic still loses.
- Most duplicate-content problems are self-inflicted: parameters, pagination, and both www and non-www resolving.
- Fix crawl and indexation before performance. A fast page nobody indexes earns nothing.
On this page
The three faults that actually cost rankings
Almost every technical problem worth fixing is a variation of reach, render or duplication. Everything else in a typical audit report is hygiene: worth doing eventually, but it will not explain why a page is not ranking.
| Fault | What it looks like | Where to confirm it |
|---|---|---|
| Cannot reach | Page is not in the index at all | Search Console URL Inspection |
| Cannot render | Indexed but with missing or wrong content | URL Inspection, rendered HTML tab |
| Duplication | Several URLs competing, none ranking well | Search Console Pages report |
Crawl and indexation
Indexation is binary and it is the only technical issue that can reduce a page to zero. Check it first, on the specific URLs that matter, not in aggregate.
The Pages report in Google Search Console groups every excluded URL by reason. Read the reasons rather than the totals: a site with 4,000 excluded URLs may be perfectly healthy if they are all tag archives you never wanted indexed.
Exclusion reasons worth acting on
- Discovered – currently not indexed. The engine knows the URL and chose not to fetch it. Usually a quality or crawl-budget signal, not a bug.
- Crawled – currently not indexed. It looked and declined. Almost always thin or duplicate content.
- Blocked by robots.txt. Check this immediately after any redesign. It is the single most common catastrophic launch error.
- Excluded by
noindex. Same as above. Staging settings that survive a launch cause most of these. - Alternate page with proper canonical tag. Normal and healthy, unless the canonical points somewhere you did not intend.
Two exclusion reasons are frequently misread as problems when they are not: Page with redirect and Not found (404). Both are correct outcomes for URLs that should redirect or should be gone.
Duplication, mostly self-inflicted
Duplicate content rarely means someone stole your copy; it means your own site serves the same page at several addresses. The engine then has to pick one, and it does not always pick the one you would.
- Make sure only one of
http,https,wwwand non-wwwresolves. The other three should redirect, in one hop. - Set a self-referencing canonical on every indexable page.
- Decide what happens to URL parameters from filters, sorting and tracking. Canonical them to the clean URL unless the filtered view is genuinely a page someone would search for.
- Leave paginated archives alone. Page two should canonical to itself, not to page one, that is a long-standing myth that removes deep pages from the index.
- Consolidate near-identical service or location pages. Three pages that differ only by city name usually rank worse than one good page.
Rendering and JavaScript
If your main content only appears after JavaScript runs, treat indexing as slower and less reliable, not impossible. Google renders JavaScript; it just does it on a second pass, and other crawlers frequently do not.
The test is quick: use URL Inspection, request a live test, and read the rendered HTML. If your headings, body copy and internal links are present, rendering is fine. If you see an empty shell, every downstream signal is compromised.
Answer engines raise the stakes here. Several of the crawlers behind AI answers execute little or no JavaScript, so content that depends on it can be invisible to them while ranking perfectly well in classic search.
Where performance genuinely counts
Core Web Vitals decide close contests and affect conversion far more than they affect position. Improving from poor to good is worth doing; chasing a perfect score is not.
| Metric | Good | Usual cause of failure |
|---|---|---|
| LCP (loading) | Under 2.5s | Oversized hero image, slow server response |
| INP (responsiveness) | Under 200ms | Heavy third-party scripts blocking the main thread |
| CLS (visual stability) | Under 0.1 | Images and embeds without reserved dimensions |
Two changes fix most failing sites: give every image explicit width and height attributes, and remove or defer the third-party scripts nobody can name an owner for. Tag managers accumulate these the way a garage accumulates paint tins.
When the problem is structural rather than a stray script, our Core Web Vitals fix works through the render path and hands back a site that passes on real user data.
A perfect performance score on a page with nothing worth reading is an expensive way to lose slowly.
Serhii Yelbaiev, Well Web Marketing
Frequently asked questions
Once properly, then after every significant change: a redesign, a migration, a platform upgrade. Continuous monitoring of indexation in Search Console matters far more than a quarterly report.
Yes, and it should list only canonical, indexable URLs. A sitemap full of redirects and noindex pages sends a confusing signal about which pages you consider important.
It is a real but small one, and it acts mostly as a tiebreaker between comparable pages. Its larger effect is on conversion, where the impact is immediate and measurable.
Not below roughly ten thousand URLs. Small sites almost never hit a crawl budget ceiling; they hit quality thresholds and mistake it for one.
Sources and method
Thresholds for LCP, INP and CLS are the public Core Web Vitals targets as defined by the Chrome team. Exclusion-reason behaviour reflects Google Search Console reporting as of early 2026. Fault-class frequencies come from our own audit work on small and medium sites. Last reviewed February 2026.