You published the site, you waited, you searched for it \u2014 and Google acts like it doesn’t exist. It’s one of the most stressful problems in running a website, partly because the feedback loop is so slow and partly because most advice you’ll find starts by telling you to submit a sitemap you submitted three weeks ago.<\/p>\n
The good news: indexing problems fall into a small number of buckets, and there’s a reliable order to check them in. The bad news: one of those buckets is “Google looked at your page and decided not to keep it,” and no plugin fixes that one. Expectations first, then the ladder.<\/p>\n
Two things worth internalising before you start changing settings.<\/p>\n
A brand-new site takes weeks, not hours.<\/strong> A domain with no history and no links pointing at it gets crawled slowly. Two to four weeks before the homepage and a handful of pages appear is ordinary; deeper pages can take a couple of months. If your site went live last Tuesday, nothing is broken yet.<\/p>\n Indexing is never guaranteed.<\/strong> Google’s own documentation is explicit that it doesn’t index every page it crawls and there’s no way to force it. Sitemaps, Request Indexing, pinging APIs \u2014 all requests<\/em>. Google decides. A thin or near-duplicate page can sit in “Crawled \u2013 currently not indexed” forever, and that’s the system working, not a bug.<\/p>\n The useful mental model: remove every technical reason Google can’t<\/em> index a page, then give it a reason to want<\/em> to. Most people only do the first half.<\/p><\/blockquote>\n Don’t guess. Two free checks tell you which bucket you’re in within five minutes.<\/p>\n Search Google for If you don’t have Google Search Console<\/a> set up, stop and do that now \u2014 you’re troubleshooting blind without it. Then use URL Inspection<\/strong> (the search bar at the top) for the state of one specific URL, and the Page indexing<\/strong> report (formerly Index Coverage) for the site-wide picture, which splits URLs into indexed and not indexed with a “Why pages aren’t indexed” table underneath.<\/p>\n Those status names are the actual diagnosis, so it’s worth knowing what they mean rather than what they sound like:<\/p>\n These make indexing impossible regardless of content quality. Check in this order \u2014 the first accounts for a startling share of cases.<\/p>\n Go to Settings \u2192 Reading<\/strong> and look for Search engine visibility: Discourage search engines from indexing this site<\/em>. If it’s ticked, untick it. It gets switched on during development and forgotten at launch constantly \u2014 the single most common cause of a completely unindexed WordPress site. Some hosts tick it on staging installs and it survives the clone to production.<\/p>\n Visit Yoast, Rank Math, SEO Framework and friends all set Every page should have a self-referencing canonical unless you deliberately want it consolidated elsewhere. A site-wide canonical pointing every page at the homepage \u2014 hardcoded by a theme or migration plugin \u2014 will quietly de-index everything. Check the source for A “coming soon” plugin, HTTP basic auth, or a staging site left password-protected all return content Googlebot can’t read, as do cookie walls that block the page body until interaction. Use URL Inspection’s Test live URL<\/strong> to see the rendered HTML Google actually receives.<\/p>\n Overzealous security plugins, WAF rules, Cloudflare bot-fighting settings and country blocks can all return 403s to Googlebot. Search Console’s Crawl stats<\/strong> report (under Settings) shows response codes over time \u2014 a wall of 403s or 5xx there is your answer.<\/p>\nStep 1: Find out what’s actually happening<\/h2>\n
The site: search<\/h3>\n
site:yourdomain.com<\/code>. The result count is a rough estimate, not a metric, but it answers the binary question. Zero results means nothing is indexed, which points at a site-wide blocker. Homepage but no posts means discovery or quality. Narrow to one page with site:yourdomain.com\/your-post-slug\/<\/code>.<\/p>\nSearch Console URL Inspection and the Page indexing report<\/h3>\n
\n
Step 2: Rule out the hard blockers<\/h2>\n
The “Discourage search engines” checkbox<\/h3>\n
robots.txt disallow<\/h3>\n
yourdomain.com\/robots.txt<\/code>. Disallow: \/<\/code> under User-agent: *<\/code> blocks everything. The nuance worth knowing: robots.txt blocks crawling<\/em>, not indexing \u2014 and blocking a page stops Google seeing any noindex<\/code> tag on it. To remove a page from the index, let it be crawled and use noindex<\/code>; never both.<\/p>\nA noindex tag from your SEO plugin<\/h3>\n
noindex<\/code> per post, per post type and per taxonomy. Check the post’s SEO panel (advanced settings), then the site-wide defaults for that content type. Then view the page source and search for noindex<\/code> \u2014 the output is the ground truth, not the plugin’s UI.<\/p>\nThe wrong canonical<\/h3>\n
<link rel=\"canonical\"<\/code>.<\/p>\nPassword, staging or maintenance protection<\/h3>\n
Your server or firewall blocking Googlebot<\/h3>\n
Symptom \u2192 likely cause<\/h2>\n