Why isn't my WordPress website showing up in Google when everything seems fine?
If your WordPress site isn't showing up in Google even though everything seems fine, it's almost always a block such as noindex or robots, a sitemap or canonical issue, or a stack of thin pages that Google doesn't want to pick. A thirty-minute diagnosis finds the cause. In this article you'll go through the same checks we use internally.
The quick check that fixes it instantly for many sites
Your site is live, your page loads, you have a sitemap. And yet you see that blunt line in Search Console: URL is not on Google. In practice it's rarely magic. So don't start by rewriting content or building links, but with two checks you can do within five minutes.
Check 1: WordPress reading settings
- Go to Settings and then Reading.
- Check that the option to discourage search engines is switched off.
- Was it on? Switch it off, save, and then test a live URL in Search Console.
Why this happens so often: many sites are first built in a temporary phase. That setting sometimes stays on by accident after going live.
Check 2: robots and noindex signals
- Open /robots.txt and check whether a Disallow rule is blocking everything.
- Search your page's source code for a meta robots tag containing noindex.
- Watch out for caching: you may have fixed something while the old version is still being served.
- Run a live test in Search Console. The live test always beats your gut feeling.
Reality check: if you fix this and your URL can be indexed live, then the problem was never your content, your links or your authority. There was simply a lock on the door.
The real WordPress causes that keep coming back
If the problem persists after the quick check, the cause runs deeper. These are the four layers we keep seeing in practice. A hacked or neglected site is the cause nobody sees, because everything on the front end just works: how updates, backups and login security stop it getting that far is covered in WordPress maintenance and security.
Sitemap and discovery
Signs that discovery is failing: many pages sit at discovered but not yet crawled in Search Console, your sitemap status stays on error, only your homepage and a handful of pages are in the index, and new posts stay invisible for weeks.
- Open your sitemap URL in the browser and check whether it contains urls.
- Check that the sitemap uses the same variant as your site: with or without www, http or https.
- Check whether caching or security plugins are blocking your sitemap for bots.
- Only then submit an indexing request for a key page.
Archives and bloat
The second classic in WordPress is bloat: tags, categories, date archives, author archives, search result pages and attachment pages. It feels like structure, but these are often thin pages that mostly contain repetition. You recognise it in Search Console by lots of excluded pages flagged as duplicate or alternate page, lots of urls with impressions at low positions and no clicks, a growing number of urls with no growth in traffic, and soft 404 reports on archives.
The nuance many people miss: tags and categories aren't wrong by definition. They work if you treat them as real hub pages, with an intro, a clear scope and internal links to your best articles. If it's just a list, it's usually dead weight.
Canonical and duplicates
Canonical issues are the silent killers in WordPress. You can have content and internal links, and Google still picks a different url as the representative version. This happens when the same post is attached to several categories and tags, when filters in webshops create parameter urls, when a page exists in two variants because of www or a trailing slash, or when two pages have almost the same content.
- Open URL Inspection and look at the canonical Google has chosen.
- Does it differ from your choice? Then that's your starting point.
- Check that your internal links point to the variant you want to win.
- Consolidate overlap: one page needs to be in charge.
Speed and rendering
The fourth layer is performance and rendering. Too many plugins, heavy page builders, too many scripts and content that only appears after interaction. Signs: a slow TTFB and large script bundles, especially on mobile, Core Web Vitals that stay red or orange, pages that do get crawled but take a long time to get indexed, and a screenshot in Search Console with missing content.
The practical truth: it's almost never about the number of plugins, but about what they inject into your front end. One plugin can slow down your whole site, and one good caching approach can give you real stability.
Diagnosis in five steps
This way you'll quickly know why Google isn't picking up your url. Work through the steps in this order.
Step 1: run a live test on one key page
Pick a page you genuinely want to rank. Open URL Inspection, run the live test and look at indexability. If Google says indexing isn't possible, it's technical or a block. No argument.Step 2: check the chosen canonical
If Google picks a different url than you, don't write extra content, consolidate instead. The right url needs to win in internal links and in your templates.Step 3: check your sitemap and crawl stats
Make sure your sitemap is populated, reachable and contains the right url variant. No visits from Google often means discovery, hosting or a block.Step 4: filter your index report by pattern
Don't look at the total, look for a pattern: duplicate, discovered, crawled but not indexed, soft 404 or alternate page. That pattern determines your action.Step 5: check bloat and internal hierarchy
If you have thousands of thin pages, indexing isn't an on-off problem but a selection problem. Then you clean up, build hubs, steer internal links and bring your most important pages closer to the homepage.| Step | What you do | What that rules out |
|---|---|---|
| 1 | Live test on a key page in URL Inspection | noindex, robots block, server error |
| 2 | See which canonical Google itself has chosen | canonical pointing to another page |
| 3 | Compare your sitemap with what's actually in the index | urls that were never submitted |
| 4 | Look for pages targeting the same topic | cannibalisation between your own pages |
| 5 | Check security, updates and unwanted redirects | hacked or neglected without you noticing |
| ▶ | Nothing left to rule out | then it's a content issue, and only then is rewriting worthwhile |
Fixes per cause, without chaos on your site
Noindex or robots block
First fix WordPress's reading settings and your SEO plugin's templates. Also check your caching layers, because after the fix you want Google to see the new version. Run a live test and then an indexing request on one page. Don't expect an instant result across the board: Google revisits pages in batches, so start with your key pages and let the rest follow.
Sitemap issues or the wrong url variant
Make sure your sitemap returns a 200 status and contains urls. Let one variant win: www or not, always https, trailing slash consistent. Update your internal links to that one variant. Watch out for security plugins and firewalls: they sometimes block bots on sitemap endpoints. If you have a webshop, tackle the template level straight away too, because many duplicate urls come from filters and parameters.
Tag, category and attachment bloat
Set thin archives to noindex or turn them into real hub pages. Remove tags you never use and that don't represent a theme. Disable attachment pages or redirect them to the media file, and remove internal links to worthless archives so bots spend less time on them.
Google picks a different canonical
Stop creating extra pages that touch on the same topic. Choose one main url and make it stronger with internal links, a better title and clearer intent. Consolidate overlap with redirects where needed and check that your canonical links are correct at template level.
Slowness and heavy scripts
Identify scripts that load on every page without needing to. Optimise above the fold: LCP and INP are often the bottleneck. Use caching and image optimisation, but avoid stacking plugins. And don't let score obsession drive you mad: focus on the templates that carry traffic and revenue, the rest can follow later.
Crawled but not indexed
This is usually not an error but a quality or selection signal. Sharpen the page up: answer directly, give proof and examples, and choose a clear scope. Strengthen internal links from pages that already have authority, and remove or merge pages that serve the same purpose.
Not sure whether your current site can still cope with this technically? Also read what it costs to have a website built. Then you'll know where you stand before you start rebuilding.
The index report, message by message explained
Step 4 above says: look for a pattern in your index report. That only works if you know what those messages mean, and the names Google uses are precise enough to be confusing. Below they're given exactly as Google labels them, with what they mean and what to do about them. The full list of statuses is in Google's own explanation of the Page indexing report, checked on 25 August 2026.
The messages that say: there's a lock on it
URL blocked by robots.txt
Google isn't allowed to fetch the page. Watch out for the trap: this isn't a noindex. A page blocked by robots.txt can still appear in the results without a description, because Google knows the url but not the content. If you actually want something out of the index, use noindex and don't block it, otherwise Google can never read that noindex.URL marked noindex
Here the answer is unambiguous: something is setting that tag. In WordPress that's usually the reading settings from the quick check, a per-post-type setting in your SEO plugin, or a checkbox in that one page's sidebar.Server error (5xx)
and Not found (404). The page gave no usable response at the moment of crawling. For a 5xx on a handful of urls, look at your hosting and at plugins that fall over under peak load. For a 404, check whether the url ever existed and whether internal links point to it that you need to clean up.Blocked due to unauthorized request (401)
and Blocked due to access forbidden (403). This is the classic case for a site still sitting behind a password or a firewall rule. Security plugins that keep out bot traffic are the usual culprit here, and they end up keeping out the bot you actually want too.The messages that say: a different page was chosen
- Alternate page with proper canonical tag. This is usually good news. Google has followed your canonical and is indexing the page you pointed to. You only have work to do if the chosen target page isn't the one you want to win.
- Duplicate without user-selected canonical. There are several near-identical urls and you haven't designated which one is in charge. Pick one and point your internal links there.
- Duplicate, Google chose different canonical than user. This is the most annoying one, and also the most instructive. You designated a page and Google chose a different one. Writing extra text doesn't help here. What does help: removing the overlap, and tightening your internal links and sitemap around your chosen url so tightly that Google has no reason left to overrule you.
- Page with redirect. The url redirects, so it doesn't belong in the index. Only a problem if the redirect chain is longer than one step, or if urls that redirect are still sitting in your sitemap.
The two messages that come with no button
- Discovered, currently not indexed. Google knows the url but hasn't fetched it yet. This is a crawl budget and priority signal. It happens a lot on sites with lots of thin urls: the bot then has so much to do that your new page ends up at the back of the queue. Cleaning up helps more here than an indexing request.
- Crawled, currently not indexed. Google has read it and decided not to include it. This isn't an error and it comes with no button. It's a selection judgement, and the answer is about content: does this page answer a question someone actually asks, is that answer at the top, and is there anything on it that can't be found anywhere else.
- Soft 404. The page returns a 200 status but reads like an empty or error page. In WordPress this often comes from empty archives, search result pages and category pages with no posts.
Work through this report from top to bottom by count, not alphabetically, and deal with the messages from the first group first. Opening a lock is a fix. The last two messages aren't a fix but a judgement, and you only start on those once the locks are gone.
Where noindex hides in WordPress
The quick check at the top catches the two best-known spots. If the message persists even though you're sure you've covered those two, it's in one of the places below. They're listed in order of how often we come across them.
Per post type in your SEO plugin
Every major SEO plugin has a screen where you set, per type, whether it's allowed to appear in search results: posts, pages, media, and any post type a plugin or your theme has added. One toggle there sets hundreds of urls to noindex at once, and you won't see any of it on the page itself.Per page, in the sidebar or below the editor
Often a collapsible panel with advanced settings. Someone once shielded a draft and the checkbox stayed ticked.Per taxonomy
Categories, tags and every custom taxonomy have their own switch. This is usually a deliberate choice and so not wrong, but it is the explanation if you're missing your category pages.An X-Robots-Tag in the HTTP header
This one is the hardest to find, because it's not in your source code. It comes from your server, from an .htaccess rule or from a plugin. You only see it in your browser's network tab or in Search Console's live test. A page whose source code is clean but where Search Console still reports noindex is almost always this.A maintenance or coming-soon plugin
These shut the whole site off for anyone who isn't logged in. Because you are logged in, your site looks perfectly fine to you. Log out in a private window and look again.A staging environment that became the original
When moving from staging to live, the setting to discourage search engines sometimes comes along instead of getting switched off. Check that one checkbox after every migration, and check that the urls in your database point to the real domain.A caching layer still serving the old version
You've fixed it, but the visitor and the bot are still getting the stored copy with the old tag. Clear your cache after every change to robots or canonical settings, including the cache at your hosting provider and at any CDN.Two rules of thumb that save you a lot of time here. First: the live test in Search Console always beats your source code, because that test also sees headers and server responses. Second: change one thing at a time and then test. Flip three switches at once and afterwards you won't know which one it was, and next time the search starts all over again. The broader technical background is in technical SEO.
AI and the search results in 2026
In 2026 you see more panic because the search results page is changing. People search for their own brand, see AI blocks and more adverts, and think Google isn't showing their site any more. Sometimes that feeling is right, sometimes it isn't.
The shortest summary: if Google can't index your url, it's technical or a block
If Google can index it but doesn't choose your page, it's selection, duplication or quality. You need to be clear on that difference first. Want to know how AI search is developing further? Also read what's changing in ChatGPT and what to watch out for.
Frequently asked questions about WordPress sites not showing up in Google
How long does it take before Google indexes my WordPress site?
If everything is set up correctly it can go quickly, but there's no guarantee. More important is whether Google can index your page and whether your site has enough signals to be chosen. Start with a live test and the chosen canonical.
Why does Search Console say my URL isn't on Google?
That only means the url isn't currently in the index. It doesn't yet say why. Use URL Inspection and look at indexability, canonical choice and any blocks.
What's the most common problem with WordPress indexing?
Noindex settings, robots rules or bloat from archives and tags. That's why you always start with the quick check.
Should I let tags and categories be indexed?
Only if you build them as real hub pages with an intro and internal links. If they're just lists, noindex is usually the smarter move to avoid dilution.
Does it help to submit an indexing request for everything?
Not if the underlying cause hasn't been fixed. An indexing request is an accelerator, not a repair. Fix blocks, canonical confusion and template issues first, and then start with your most important pages.
Can a plugin update knock my site out of Google?
Yes. Especially if the update touches templates: meta robots, canonical logic, structured data, internal links or performance. So after updates, check your index report and run one live test.
My site is fast but still isn't getting indexed, how is that possible?
Then it usually comes down to selection: too much overlap, too many thin pages or unclear intent. Make one main page stronger and consolidate the rest.
Where do I start without technical knowledge?
Start with WordPress's reading settings, then robots.txt, then the live test in URL Inspection. If all of that checks out, look at archives and duplicates.
Let us take a direct look at your WordPress site
Want us to work this out exactly for your site? You get not just a diagnosis but also a plan that won't wreck your site: what you fix at template level, what you rebuild, which pages need to win and how you steer the internal structure. Check out our SEO improvement service for this.
Would you rather learn more yourself first? In our knowledge base you'll find more practical explanations about indexing, speed and findability. If you decide you want help with this, screen your developer first with the eight questions from hiring a WordPress specialist.
There's one situation where searching this out yourself is a waste of your time: you've covered all the locks from the first group of messages, your live test says indexing is possible, and Google still doesn't include your page. At that point it's no longer about a switch but about selection, and you won't solve that with a manual. If you run into that, book a call via contact.
Bring two things: the message that appears most often for your urls in the Page indexing report, and the url that Google has chosen as the canonical. With those two pieces of information, we'll know within half an hour whether you have a technical problem, a structural problem or a content problem, and those three each have a different answer and a different price tag.
Want your own baseline check first? Take the free SEO scan. It runs through 24 points of your site and gives you exactly the kind of checklist that keeps a call like that short.