WordPress And Crawl Errors: What To Fix vs What To Ignore

Google Search Console reports crawl errors and indexing issues across various categories. Sites with significant content can accumulate hundreds or thousands of reported issues. Treating all of them as equally important wastes effort. Ignoring all of them misses real problems.

The triage that distinguishes urgent issues from normal noise depends on understanding what each category means and why URLs end up in each one.

The categories Search Console reports

Search Console's Pages report (formerly Coverage report) categorizes URLs into: Indexed, Discovered (currently not indexed), Crawled (currently not indexed), Excluded (with specific reasons like noindex, canonical, robots.txt block).

The error categories: Server errors, Redirect errors, URL is blocked by robots.txt, Soft 404, Page with redirect, Not found (404).

Each category has its own pattern of seriousness and fix difficulty.

What needs urgent attention

Server errors (5xx HTTP responses) reported at scale. A few server errors are normal; hundreds suggest a systematic issue. The fix: investigate server logs to understand what's failing, address the underlying issue.

Soft 404 errors on important pages. Soft 404 means the page returns 200 status but Google thinks it's a not-found page. Often happens when a page has very thin content or matches the pattern of a 404 page. The fix: add substantive content to the page or properly redirect/404 the URL.

"Excluded by 'noindex' tag" on URLs you didn't intend to noindex. The fix: find why the noindex was added (often an SEO plugin setting), remove it, request reindexing.

"Page with redirect" reports showing chained redirects (URL A → URL B → URL C → final). The fix: make redirects single-hop (URL A → final).

"Crawl anomaly" at scale. The category catches issues that don't fit other categories. If many URLs show crawl anomaly, investigate the pattern.

What needs eventual attention

"Discovered, currently not indexed" on cornerstone content. Google has seen the URLs but chose not to index them. Often signals quality concerns or low priority. The fix: improve the content, build internal links, request indexing.

"Crawled, currently not indexed" similar to above. Google crawled but didn't index. The fix is similar.

"Duplicate without user-selected canonical." Google is treating URLs as duplicates and choosing its own canonical. The fix: set explicit canonical tags to indicate your preferred URL.

Specific 404 errors on URLs that should exist. These often trace to internal links pointing to old URLs after migrations. The fix: update internal links to point to current URLs, set up redirects for the old URLs.

What is usually normal noise

404 errors on URLs from external sites. Some external site has an outdated link to your site; their link is wrong, not your site. The fix is usually nothing; let it persist.

"Page with redirect" on category, tag, and date archive URLs. WordPress has many URL patterns that redirect to canonical versions. The redirects are intentional. Not a real issue.

"URL is blocked by robots.txt" on /wp-admin/ and similar paths. The blocking is intentional. Not a real issue.

"Crawled, currently not indexed" on tag pages or low-content category pages. If you didn't intend for these to be indexed (because they're thin), Google's choice is correct.

"Excluded by 'noindex' tag" on URLs you intentionally noindexed (admin pages, account pages, cart pages). Google is following your instruction. Not an issue.

The 404 deep dive

404 errors are the most common Search Console reports and the most often misinterpreted. The pattern:

404 errors from external sources with bad links: ignore. You can't control external link quality.

404 errors from internal sources (your own site linking to non-existent URLs): fix. Update the links to point to actual content.

404 errors on URLs that used to work but were intentionally removed: set up 301 redirects to the appropriate replacement URLs, or accept the 404 if no replacement exists.

404 errors on URLs that match a query pattern (search results, filter combinations, dynamically-generated URLs): consider blocking via robots.txt to prevent crawl budget waste.

404 errors on URLs that are typos of real URLs (someone shared a misspelled URL): consider 301 redirecting to the correct URL, especially if the typo gets significant traffic.

The redirect chain problem

Search Console reports redirect chains as "Page with redirect" with specific URLs. The chain might be: /old-post/ → /old-permalink-structure/old-post/ → /new-post/ → /final-canonical-url/.

Each step in the chain adds latency. Crawlers might give up after a certain number of hops. The fix: replace the chain with single-hop redirects.

For each old URL in the chain, set a direct redirect to the final canonical URL. Skip the intermediate hops.

WordPress redirect plugins (Redirection, Yoast's redirect manager, Rank Math's redirect manager) handle this. The audit: export the redirect list, check for chains, replace chains with direct redirects.

The "Discovered, not indexed" investigation

When Google says it discovered URLs but didn't index them, the implicit message is "we don't think these are worth indexing." The reasons vary:

Content quality below threshold. The pages might be too thin, too templated, or too duplicative of other content on your site or elsewhere.

Crawl budget allocation. Google decides which URLs to prioritize. Pages with stronger signals get indexed; weaker ones get discovered but not indexed.

Technical signals. If pages have low engagement signals (high bounce rate, low time on page), Google might deprioritize them.

The investigation: pick 10 URLs from the "Discovered, not indexed" list. Evaluate the pages honestly. Are they substantive? Are they meaningfully different from other pages on the site? Do they answer specific search queries?

If the pages are genuinely low-value, accept the deprioritization or consider consolidating with other content. If the pages are genuinely valuable, the issue is signal-related and addressing the signals (internal linking, content improvement, structured data) might trigger indexing.

The strategic approach

Rather than fixing every Search Console issue, prioritize:

1. Fix issues that affect important traffic-driving pages. A 404 on a top-ranking post matters; a 404 on a archive page from 2018 doesn't.

2. Fix systematic issues that affect many URLs. A misconfigured plugin causing 200 URLs to be wrongly noindexed deserves attention.

3. Ignore noise that doesn't affect anything important. Random 404s from external bad links, intentional excludes, normal redirect patterns.

4. Monitor for new issue categories that weren't there before. New issues at significant volume signal something changed.

The honest framing

Search Console's report categories are useful but require interpretation. Treating the reports as a complete to-do list produces busywork; treating them as triage input produces focused work.

Most WordPress sites have hundreds of "issues" reported in Search Console. Most of those issues don't need fixing. The skill is distinguishing the ones that do from the ones that don't.

The pattern that works: weekly review of new issues, monthly review of overall trends, quarterly audit of the full report. The discipline catches real problems while not generating unnecessary work for normal noise.