Problem library
Start with the visible symptom. Each path states what usually breaks, the checks that separate causes, and how the first sprint is verified.
Diagnostic routing
If WordPress pages are stuck as Crawled currently not indexed, Discovered currently not indexed, Duplicate without user-selected canonical, or simply missing from search, the first step is not rewriting everything. The first step is checking whether WordPress is sending mixed indexability signals.
WordPress speed problems are usually not solved by toggling every optimization setting. The useful path is finding whether the bottleneck sits in server response, render timing, template weight, plugin JavaScript, fonts, cache, or CDN behavior.
WooCommerce tracking failures usually sit around event timing, dataLayer state, thank-you page logic, duplicate tags, or browser and server deduplication. The fix starts by proving where the event path breaks.
Form and lead tracking failures often come from AJAX submits, thank-you page assumptions, duplicate tags, plugin-injected tracking, consent behavior, or GTM triggers that do not match the real user path.
After a WordPress relaunch, the damage usually comes from a handful of failure paths: staging noindex, redirect gaps, canonical drift, sitemap changes, internal links still pointing to old paths, or tracking moving in a way that hides what happened.
If Google has crawled a WordPress URL but left it out of the index, resubmitting the URL is usually not the fix. The first pass is checking whether the URL looks duplicate, weak, conflicted, or unsupported by internal links.
Discovered currently not indexed often means Google found the URL but has not treated it as worth crawling yet. On WordPress sites, the cause commonly sits in crawl priority, internal linking, sitemap-only pages, weak archives, or unstable server response.
A staging noindex problem is usually a signal mismatch, not a content problem. The fix starts by checking every layer that can tell crawlers to stay away: WordPress settings, SEO plugin output, HTTP headers, robots files, and staging leftovers.
When Google selects a different canonical than the one WordPress declares, the first check is whether the page sends mixed preference signals through templates, internal links, sitemap entries, parameters, archives, or duplicate content.
A sitemap should point crawlers at canonical, indexable URLs. If WordPress sitemaps contain redirected URLs, the issue usually sits in plugin-generated sitemap state, migration leftovers, old taxonomy or product URLs, stale cache, or redirect chains.
NO PERFECT MATCH?