You published a page, checked back a few days later, and it is nowhere in Google. Maybe it is one page. Maybe it is the whole site. Either way, the fix is almost always findable if you check the right things in the right order, rather than guessing. This guide walks through that order.
Diagnostic decision tree: work through this top to bottom
Check WordPress search engine visibility
Settings > Reading. Is 'Discourage search engines from indexing this site' checked? If yes, uncheck it. This one setting explains most launch-day indexing failures.
Check for a stray noindex tag
View page source and search for 'noindex' in the meta robots tag. If present and unintended, find and remove it in your SEO plugin or theme.
Check robots.txt
Visit yoursite.com/robots.txt. Confirm it is not disallowing the page or the whole site, and that it references your sitemap.
Check sitemap submission
In Search Console, go to Sitemaps. Confirm your sitemap URL is listed, was fetched successfully, and includes the page in question.
Check the Search Console coverage report
Look up the specific URL in the URL Inspection tool. Read the exact status Google reports rather than assuming.
Request manual indexing
If everything above checks out and the page is genuinely eligible, use 'Request Indexing' in URL Inspection to nudge Google to crawl it sooner.
The "Discourage search engines from indexing this site" setting
This is the single most common cause of a WordPress site not getting indexed, and it is almost always accidental. WordPress ships with a checkbox that tells search engines not to index the site at all. It lives in Settings > Reading, under a section labeled Search Engine Visibility, with the checkbox text "Discourage search engines from indexing this site."
The setting exists so developers can build a site without it leaking into search results before launch. Most hosts and agencies check this box automatically when they spin up a staging or development install. The problem is what happens next: the site goes live, the content gets built out, the client starts publishing, and nobody remembers to go back and uncheck it. WordPress does not warn you when this happens. There is no banner on the dashboard, no email, no admin notice once the site is public. The box just stays checked, silently telling Google to stay away, sometimes for months.
When this setting is on, WordPress adds `<meta name="robots" content="noindex,nofollow">` to every page's HTML head, and it also asks your sitemap and robots.txt behavior to fall in line. It affects the entire site, not just one page, which is why this is usually the first thing to check when nothing is showing up in search at all rather than just one or two pages.
Check this first, every time
Before you touch anything else, go to Settings > Reading and confirm the box is unchecked. If it was checked, uncheck it, save, and give Google a few days to recrawl before assuming you have a bigger problem.
It is worth checking this setting again after any migration, staging-to-production push, or hosting change, since these are the exact moments a developer is likely to re-enable it and forget to reverse it. Rankwyn's site maintenance checks flag this setting automatically so it does not sit unnoticed after a deploy.
A noindex tag left in your theme or a plugin
If the visibility setting above is unchecked but the page still is not indexing, the next place to look is the actual HTML of the page. View the page source (or use your browser's inspect tool) and search for the word "noindex" inside a `<meta name="robots">` tag in the `<head>`.
A few common ways a noindex tag ends up somewhere it should not be: a theme template hardcodes a robots meta tag for a specific page type, like an archive or search results template, and that code accidentally applies to regular posts too. A caching or staging plugin left a noindex directive active after the site went live. An SEO plugin has a per-page or per-post "noindex this page" toggle, and it got switched on by mistake, sometimes by someone editing the post who did not realize what the field did. A category, tag, or custom taxonomy archive is set to noindex site-wide as a deliberate choice, and a page you expected to be indexed is actually living on that archive template.
The fix depends on where the tag is coming from. If it is a per-page setting in your SEO plugin, open that specific post or page, find the robots meta control, and set it back to index. If it is coming from a theme template, you will need to edit the template file or use a child theme override. If it is a deliberate site-wide setting that is simply misconfigured for this content type, adjust the plugin's global robots meta settings for that post type or taxonomy.
Do not confuse a noindex tag with a canonical tag pointing elsewhere. A canonical tag pointing to a different URL will also keep a page out of the index under its own URL, but the fix is different: you either accept that the other URL is the correct canonical, or you correct the canonical tag if it is wrong.
Your sitemap is not submitted, or robots.txt is blocking it
Google can index pages it finds through links alone, without a sitemap, but a sitemap makes discovery faster and more reliable, and a broken one can actively cause problems. Start by checking two things separately, because they are different failure modes.
robots.txt is blocking the page or the sitemap
Visit `yoursite.com/robots.txt` directly in a browser. Look for a `Disallow` rule that matches the URL path of the page in question, or a blanket `Disallow: /` that blocks the entire site. This sometimes gets left in place after a migration, or gets added by a security plugin that was configured too aggressively. Also confirm the file lists your sitemap location with a `Sitemap:` line. If robots.txt is missing that line, or pointing to a sitemap URL that no longer exists, Google has to fall back to discovering pages purely through crawling links, which is slower.
The sitemap was never submitted, or Google could not fetch it
In Search Console, open the Sitemaps report under Indexing. If you do not see your sitemap URL listed at all, it was never submitted, and Google is not using it to guide discovery. If it is listed but shows an error status, fetch the sitemap URL yourself in a browser and confirm it loads as valid XML rather than a blank page, a 404, or an HTML error page. A sitemap that references pages behind a login, or that includes URLs that redirect or 404, will also generate warnings and reduce Google's trust in the file.
If the sitemap loads fine and is submitted but the specific page you care about is missing from it, that usually points to a plugin configuration issue, such as a post type or category being excluded from the sitemap generator. Rankwyn's sitemap and indexing tools build and validate the XML sitemap automatically and can flag excluded content before it becomes a mystery three weeks later. For a full walkthrough of getting the sitemap itself right, see how to create an XML sitemap in WordPress.
The site is simply too new
If you launched recently, indexing delay may not be a bug at all. Google has to discover your site, crawl it, evaluate it, and decide to index it, and each of those steps takes time on a domain with no crawl history and no existing signals pointing to it. A brand-new domain does not have an established crawl pattern yet, so Googlebot may visit infrequently at first.
This is normal and it is not something you can force past through settings changes. What actually helps is giving Google reasons to find and prioritize the site: a submitted, valid sitemap, internal links between your pages so the crawler can move through the site once it arrives, and at least a few external links pointing in from other sites, since inbound links are one of the signals that tell Google a domain is worth crawling regularly. None of this guarantees a specific timeline, but it shortens the wait more reliably than repeatedly requesting indexing on the same handful of pages.
What "Discovered" and "Crawled, currently not indexed" actually mean
If you have checked everything above and a page is still not indexed, the URL Inspection tool in Search Console will tell you exactly where Google's process stopped. Two statuses show up constantly and get misread as the same problem. They are not.
| Status | What it means | What to do |
|---|---|---|
| Discovered, currently not indexed | Google knows the URL exists, usually from your sitemap or a link, but has not crawled it yet. This is often a crawl budget or scheduling issue, not a quality judgment. | Be patient, make sure the page is easy to reach through internal links, and confirm nothing else on this list is blocking it. |
| Crawled, currently not indexed | Google visited the page, read it, and made a deliberate decision not to add it to the index. This is a stronger signal than 'discovered' and usually relates to the page itself. | Review the page for thin or duplicate content, check whether a near-identical page already ranks, and consider whether the page adds anything a searcher cannot get elsewhere. |
The distinction matters because the fix is different. "Discovered, currently not indexed" is largely a patience and access problem, Google has not gotten to it yet. "Crawled, currently not indexed" means Google looked and passed, which points you toward the content itself: is it too thin, too similar to another page on your site, or not clearly different from what already ranks for that topic. Requesting indexing again on a page stuck in this second status rarely changes the outcome if the underlying content issue is not addressed first.
There is no setting, plugin, or trick that overrides Google's judgment on a page it has already crawled and declined to index. If a page keeps landing in 'crawled, currently not indexed,' the honest fix is usually to improve or consolidate the content, not to keep resubmitting it.
Once you have worked through the visibility setting, noindex tags, robots.txt, sitemap submission, and the coverage status for the specific URL, you have covered the realistic causes. If a site is otherwise healthy and pages are quietly making their way into the index over days rather than instantly, that is normal behavior, not a sign of a hidden bug. Tools like Rankwyn exist specifically to catch the visibility, noindex, and sitemap issues in this list automatically, so they do not sit undetected between launch and the day you notice traffic is not showing up.