In this guide
Key takeaways
- A long error list is usually a short list of causes. One broken template can produce thousands of rows, so group by issue type and by template before you count anything.
- Severity labels come from the tool, not from Google. Google says third-party tools do not have access to its internal ranking data, and their scores are the vendor's own.
- Fix in this order: can Google reach the page, can it see the content and links, is the page worth indexing, and only then polish. The 12 issues below follow that order.
- Many common warnings, such as meta description length or more than one H1, are low priority unless they point to a template fault.
- Check each fix against Google's own data in Search Console, not only against the tool that raised the flag.
Why a long error list is usually a short list of causes
When a client sends me a report with thousands of red rows, my first step is to stop counting rows and start counting causes. A crawler lists every URL that triggers a rule, so one faulty template, one bad redirect rule or one navigation link repeated on every page can produce thousands of entries from a single mistake. Fix the cause and the whole block disappears.
The second thing I check is whose opinion the label is. A crawler's "high priority" is a rule the vendor wrote. Google's own guidance on third-party tools says they do not have access to Google's internal ranking data and that their scores and predictions are the vendor's, not Google's. Useful, but not a verdict. The data I trust most for "what does Google see?" comes from Search Console, so I use the crawler to find candidates and Search Console to confirm which ones matter.
The triage rule I use
I ask three questions of every group of findings:
- Does it stop Google reaching, rendering or indexing a page that earns money or leads? If yes, it goes to the top, however few URLs are affected.
- Does it come from a shared template or rule? One fix may clear hundreds of URLs, which raises its priority.
- Is the fix cheap and low-risk? Quick, safe fixes go early. Risky changes, such as site-wide redirect rules, get tested first.
| Level | The test | Typical examples |
|---|---|---|
| Critical | Blocks crawling or indexing of important pages | Noindex on a money page, robots.txt blocking a section, server errors, a staging block left on after launch |
| High | Splits or wastes signals across many URLs, or hides content from Google | Redirect chains, canonical conflicts, wrong URLs in the sitemap, content that only exists after JavaScript |
| Medium | Weakens a page that is already indexed | Slow key templates, missing structured data where it enables a feature, weak internal links |
| Low | Cosmetic or very unlikely to change results | Meta description length warnings, a second H1, decorative images without descriptive text |
The 12 issues that matter
These are grouped by the question they answer, in the order I work through them. For each one I note how I check it. Free tools are linked where they help.
Can Google reach and index the page?
1. Important pages blocked or set to noindex. A noindex rule, set in a robots meta tag or an X-Robots-Tag header, tells Google not to show the page in results. A robots.txt Disallow stops crawling but does not guarantee a page stays out of the index, and it also hides any noindex rule on the page from Google, because Google cannot read a page it is not allowed to fetch. I check money pages one by one in the URL Inspection tool and test paths with the Robots.txt Tester. The most common cause I see is a rule left over from a staging site, and because it ships with the template it can affect thousands of pages at once, which I cover in How a Single Deploy Can Wipe Out Your Organic Traffic. The full diagnosis is in Why Your Important Pages Aren't Getting Indexed.
2. Server errors and availability. Google treats 5xx and 429 responses as a sign that your server is struggling and slows its crawling. URLs that keep returning server errors are eventually dropped from the index. I look at the Crawl stats report in Search Console for host status and the share of responses that are not 200, then at server logs for the time pattern. A firewall or security tool blocking Googlebot looks the same as a server fault from the outside.
3. Broken pages that still matter. A 404 is normal for a page that no longer exists. What matters is a 404 on a URL you still link to, list in a sitemap or that earns external links. Google's own advice in the Page indexing report is to focus on 404s you link to or submit in a sitemap. The opposite mistake is also common: a page that displays "not found" but returns a 200 status is a soft 404, and Google keeps crawling those. I test batches of URLs with the HTTP Status Code Checker.
4. Redirect problems. A permanent redirect (301 or 308) is a strong signal to move to the new URL, while a temporary one (302 or 307) is a weak signal. Google follows up to 10 hops, but advises keeping chains short, and says not to redirect many old URLs to one irrelevant page, which may be treated as a soft 404. I trace chains with the Redirect Checker and fix them at the source so every old URL goes straight to its final destination.
5. Canonical conflicts. The canonical tag is one signal among several. Problems appear when a page canonicalises to a URL that redirects, returns an error or is noindex, or when the canonical disagrees with the sitemap and internal links. Google says redirects and rel="canonical" are strong signals, sitemaps a weak one, and that it may choose a different canonical from the one you declare. I check pairs of declared and Google-selected canonicals in URL Inspection and test batches with the Canonical URL Checker.
6. A sitemap that lists the wrong URLs. Google says to list canonical URLs only, and that a sitemap is a hint and not a guarantee. It ignores the priority and changefreq tags, and uses lastmod only if it is consistently accurate. A sitemap full of redirected, noindex or error URLs wastes the one file you control that points Google at your pages. The XML Sitemap Validator flags these in one pass.
Can Google see the content and the links?
7. Content or links that only exist after JavaScript runs. Google renders JavaScript, but pages can wait in a queue first, and some designs hide links from crawlers. Google can only discover links that are anchor elements with an href attribute, so buttons and script-driven navigation can leave pages unreachable. I compare the raw HTML with the rendered HTML in the URL Inspection live test. If a key heading, paragraph or link is missing from the raw HTML, I ask whether the site should render it on the server.
8. Important pages with weak or broken internal links. Google discovers most pages through links, so a page with no internal links, an orphan, depends entirely on the sitemap. Broken internal links on key pages waste visitors' time and Google's crawling. I find both with the Internal Link Analyzer and the Broken Link Checker, then fix the link itself rather than leaving a redirect in place.
Is the page worth indexing and trusting?
9. Duplicate and near-duplicate pages at scale. Parameter URLs, filters, tag archives and printable versions can multiply one page into hundreds. Google advises eliminating duplicate content so crawling focuses on unique content, and the Page indexing report labels many of these as duplicates. The remedy is to consolidate with redirects or canonical tags, or to make the pages genuinely different. For online stores this is often the largest source of noise, and it is covered in SEO for Nepali Ecommerce. When the duplicates come from templates and data feeds on a large site, Programmatic SEO Without the Penalty Risk explains how I decide which pages should exist.
10. HTTPS and mixed content. The HTTP version of every page should redirect to HTTPS, and every resource on a secure page should load securely, because a single insecure image, script or stylesheet triggers mixed content problems in browsers. Google also prefers HTTPS pages as the canonical version. An expired certificate puts a full-screen warning between visitors and your site. I check certificates and redirects with the SSL Certificate Checker.
11. Core Web Vitals on key templates. Google's targets are LCP within 2.5 seconds, INP under 200 milliseconds and CLS below 0.1, and it says these align with what its core ranking systems seek to reward. They are one part of page experience, not a substitute for relevance. I fix the slowest template first because one change improves every page built on it. Real-user data comes first; the Core Web Vitals Checker shows it alongside a lab test.
12. Missing or invalid structured data where it enables a feature. Structured data helps Google understand a page and can make it eligible for rich results, but Google does not promise a rich result even when the markup is valid, and it must match what is visible on the page. It sits last in my list because it changes how a result looks, not whether a page is indexed. Check the markup with the Schema Markup Validator. One caution: FAQ rich results are no longer shown in Google Search, so FAQ markup added only for that feature now earns nothing in Google.
Warnings I usually park
Parking a warning does not mean it is wrong, only that it rarely changes results. I revisit these once the 12 above are clean, or sooner if they show a template fault.
| Warning | Why I usually park it | When it matters |
|---|---|---|
| Meta description too long, short or missing | Google says snippets mostly come from page content, and there is no length limit on descriptions | Key pages, where a clear unique description helps the click |
| More than one H1, or skipped heading levels | Google's starter guide says there is no ideal number of headings and that order does not matter from Search's perspective | When headings are empty, duplicated or break the reading structure |
| Missing alt text | Decorative images are better with an empty alt attribute, which is the accessibility convention | Images that carry meaning: product, diagram, screenshot. Google wants short, descriptive alt text, not keyword lists |
| Title too long | It affects display, not indexing | Duplicate or empty titles on important pages |
| Broken external links | Not your server's fault | Links your content depends on, which you should replace |
Crawler checks such as text-to-code ratio or URL length are not metrics Google documents as ranking inputs, and I do not spend time on them.
A one-hour triage workflow
- Export and group. Sort findings by issue type, then by the template or section they come from. Count causes, not rows.
- List the pages that matter. Pull your top pages by clicks and your revenue or lead pages. Check these first.
- Confirm in Search Console. Compare the crawler's candidates with the Page indexing report and the Crawl stats report.
- Test live. Inspect a sample of affected URLs with the live test to see what Google gets now.
- Assign owners. Each finding needs a person, a due date and a way to check the fix worked.
- Re-crawl and compare. After the fix, re-run the crawl and check Search Console for the validation result.
For a quick first read of a site you do not know, the Website Health Check scores speed, security, crawlability and on-page basics in one scan and puts the fixes first.
How to judge whether the fixes worked
Use measures that move when the cause is removed: fewer excluded or error URLs in the Page indexing report, a healthy share of 200 responses in Crawl stats, more of your important pages indexed, and clicks and key events on the pages you fixed. Give changes time: Google says some take effect within hours and others take several months, and suggests waiting a few weeks before judging. I do not promise percentage gains from a clean-up, because they depend on competition, the site's history and what else changes. A good report states how each fix will be verified, which is the subject of What a Good SEO Audit Report Looks Like.
If the errors came after a redesign, the cause is often in the move itself; the SEO migration audit checklist covers what to compare. And if you are unsure whether you need a narrow technical check or a wider review, which audit do you need? will help you choose.
Frequently asked questions
Do I need to fix every error my crawler reports?
No. Fix what blocks crawling, indexing or the content that earns money first. Many warnings are cosmetic. Group findings by cause and template so one fix clears many rows.
Why does my crawler show errors that Search Console does not?
A crawler follows every link it finds, including URLs Google has never prioritised, and it applies the vendor's own rules. Search Console reports what Google actually saw. When they disagree, trust Search Console for how Google treats a URL, and use the crawler to find the cause.
Should I redirect every 404 page?
No. Redirect a removed page only when a close replacement exists. Google advises returning a 404 or 410 for permanently removed pages, and warns against sending many old URLs to one irrelevant page.
Does invalid structured data hurt my rankings?
Google does not describe structured data as a ranking factor. Invalid or misleading markup can make a page ineligible for rich results, and markup that does not match visible content breaks Google's guidelines, so keep it accurate.
How long until I see improvement?
It depends on the fix. Unblocking a page can show quickly after Google recrawls it; larger structural clean-ups take longer. Google says changes can take hours to several months, so check progress against the Page indexing report rather than rankings alone.
Is crawl budget the reason my site has so many problems?
Probably not. Google says crawl budget management matters mainly for very large sites, roughly a million or more pages with weekly changes or ten thousand or more with daily changes. Most business sites, including nearly every Nepali business site I have looked at, are far smaller than that. Quality, duplication and linking are far more likely causes.
Sources and further reading
Technical statements about Google in this guide are based on the pages below, checked on 17 October 2026.
- Google Search's guidance on third-party SEO tools and advice: why tool scores are not Google data
- HTTP status codes, and network and DNS errors: 3xx, 4xx, 5xx and soft 404 handling
- Page indexing report: meaning of each status and the suggested fix
- Robots meta tag, data-nosnippet and X-Robots-Tag: noindex and its interaction with robots.txt
- How to specify a canonical URL: canonical signals and their strength
- Build and submit a sitemap: canonical URLs, lastmod, ignored tags
- JavaScript SEO basics: rendering, the queue and crawlable links
- Crawl budget management for large sites: which sites need it
- Core Web Vitals: LCP, INP and CLS targets
- Intro to structured data: rich result eligibility
- SEO Starter Guide: headings, descriptions and timing
- Google Images SEO best practices: alt text