The Setting That Hides Your Whole Site

WordPress ships with a search engine visibility option that, when enabled, asks search engines not to index the site. It exists so developers can build in peace, and it is one of the most common causes of a brand new site receiving zero organic traffic for months. You will find it under the reading settings in the admin area, where a checkbox discourages search engines from indexing the site.

When that box is ticked, WordPress adds a noindex directive to your pages and blocks crawling through the robots file it generates. Nothing else you do to improve rankings will matter while it is on. Unticking it and saving is all that is required to reverse it, but the recovery is not instant because search engines must recrawl before the pages return.

How AAMAX.CO Diagnoses and Fixes WordPress Indexing Problems

We see this issue constantly at AAMAX.CO, usually on sites that launched months ago and never gained traction. As a full service digital marketing company offering web development, digital marketing and SEO services worldwide, our technical audits check indexability first, before anyone talks about content or links, because a deindexed page cannot rank no matter how good it is. We check the core visibility setting, plugin-level directives, template-level tags, server headers, caching layers and the robots file, then verify recovery in Search Console. If your site is not appearing in search at all, our SEO services begin with exactly this kind of forensic technical check, and it is often the fastest win available.

Where the Setting Lives and How to Change It

Log into the WordPress admin, open the settings menu and choose reading. Near the bottom you will find the search engine visibility option. Ensure the checkbox discouraging indexing is cleared, then save changes. If your hosting environment locks this setting, which some staging platforms do, you will need to disable the platform-level protection first, because it overrides what WordPress reports.

Be aware that some hosts add a separate password protection or staging flag that blocks crawlers entirely at the server level. Managed hosting dashboards often expose this as a search engine indexing toggle, and it must be turned off independently of the WordPress setting.

Plugin Settings That Deindex Individual Pages

Most WordPress sites run an SEO plugin, and those plugins introduce a second layer of indexing control that operates per page, per post type and per taxonomy. Under the plugin's search appearance or content types configuration, each post type has a setting determining whether it appears in search results. If a post type such as products, portfolio items or a custom type is set to be hidden, every entry in it carries a noindex tag regardless of the site-wide setting.

The same applies to taxonomies. Category, tag, author and date archives are frequently set to noindex deliberately, which is often correct because thin archive pages can dilute crawl efficiency. However, on some sites those archives are genuinely valuable landing pages, and hiding them removes real traffic.

There is also a per-post override on the individual editing screen, usually within the plugin's advanced panel, where a single article can be excluded from search. Someone setting that during drafting and forgetting to revert it is a very common cause of one important page never ranking.

Other Places Indexing Gets Blocked

If the settings all look correct but pages still are not indexed, work through the remaining layers. Check your robots file by visiting it directly and looking for disallow rules covering the paths in question. Check for a noindex value in the robots meta tag by viewing page source, and also check the response headers for an x-robots-tag directive, which some plugins and server configurations add and which is invisible in the HTML.

Look at canonical tags too. A page canonicalised to a different URL will usually not be indexed in its own right, which is intended behaviour for duplicates but a problem when the canonical is wrong. Check for password protection or membership plugins that gate content behind a login, since crawlers see only the gate. Review caching and CDN layers, because an aggressively cached old version of a page can continue serving stale directives long after you changed them, which is why clearing all cache layers after any indexing change is essential.

Deciding What Should Be Deindexed on Purpose

Not everything should be indexed, and blanket indexing is its own mistake. Sensible candidates for exclusion include internal search result pages, thin tag archives with a single post, paginated comment pages, cart and checkout pages, thank you and confirmation pages, staging or duplicate environments, and low-value auto-generated attachment pages that WordPress creates for every uploaded media item.

Attachment pages deserve specific attention, because they are a classic source of index bloat on media-heavy WordPress sites. Most SEO plugins offer a redirect option that sends attachment URLs to the parent post, which is usually the right choice.

Author archives on single-author sites are duplicative and can be excluded. Date archives rarely serve a purpose outside news publishing. Making these decisions deliberately, rather than accepting defaults, keeps crawl attention on the pages that generate revenue.

Verifying That Indexing Has Recovered

After making changes, confirm the result rather than assuming it. Use the URL inspection tool in Search Console on a representative page to check the reported indexing status and the crawl directives the engine actually sees. If it reports that indexing is blocked, the tool tells you which mechanism is responsible, which saves considerable guesswork.

Request indexing for your most important pages, submit an up-to-date sitemap, and then watch the coverage report over the following one to three weeks. Recovery for a small site is often visible within days; larger sites recover progressively as crawl budget allows. If pages remain excluded after several weeks, revisit the header and caching checks, since those are the layers most often missed.

Preventing the Problem in Future

Build indexability into your launch checklist. Before any site goes live, confirm the visibility setting is off, the robots file allows crawling, no template contains a hardcoded noindex, staging protection has been removed, the canonical tags point to the live domain, and the sitemap is submitted. Confirm the same after every major redevelopment, because rebuilds frequently reintroduce staging configuration.

Add ongoing monitoring so you find out quickly if something changes. Search Console will email you about sudden coverage drops, and a simple uptime or SEO monitoring tool can alert you if a noindex tag appears on a key page. Catching this in a day rather than a quarter is the difference between a minor blip and a lost season of traffic, and it protects the return on everything else you invest in digital marketing.

Summary of the Fix

Clear the search engine visibility checkbox in the reading settings, confirm your SEO plugin allows indexing for the relevant post types and individual pages, remove any host-level indexing block, clear every cache layer, then verify with the URL inspection tool and submit your sitemap. Work through the layers in order and the cause almost always reveals itself within a few minutes.