WordPress Indexing Issues in Google Search Console: A Practical Troubleshooting Guide

WordPress indexing issues are frustrating because they sit between technical SEO, site build quality, content structure, hosting, and plugin settings. A page can look fine in the browser, be published in WordPress, and still be invisible in Google search.

For an owner-led service business, that matters. If your core service pages, location pages, case studies, or enquiry-led landing pages are not in the Google index, they cannot appear in search results and they cannot bring in organic enquiries. This guide explains how to diagnose the problem properly, what to fix first, and where WordPress sites usually go wrong.

At RedShaw Consulting, Gareth Redfern-Shaw usually treats indexing work as a diagnostic problem first: prove what Google can crawl, what WordPress is outputting, and which pages actually deserve indexation. If you want a second pair of eyes on this, contact RedShaw Consulting and we can review the crawl, Search Console evidence, and WordPress setup.

or drag and drop an image here

Quick answer: why your WordPress pages are not in the Google index yet

“Not indexed” means Google has not added that URL to its index. It may have discovered the URL, crawled it, or seen it in a sitemap, but it is not eligible to rank until it becomes one of your indexed pages.

On most small WordPress service sites, indexing issues usually come down to a manageable set of causes:

• the WordPress “discourage search engines” setting is still enabled;

• a noindex tag has been applied by a wordpress seo plugin;

• robots rules are blocking google from crawling the page or its resources;

• the page has weak internal links or is orphaned;

• Google sees thin or duplicate content and decides not to keep the page;

• canonical settings point Google to the wrong URL;

• server errors, redirects, or performance issues interrupt crawling.

Google Search Console is the main place to diagnose indexing problems. In practical terms, google search console tells you whether Google has seen the URL, whether crawling is allowed, what canonical page Google selected, and whether the page indexing report has indexing issues detected across multiple URLs.

The process is repeatable: confirm the indexing status, identify the pattern, map that pattern to likely WordPress causes, apply the fix, then use the url inspection tool to retest and request indexing where appropriate.

Step 1 – Confirm whether a WordPress URL is indexed

Do not start by guessing from traffic. Every indexing investigation should begin with a specific URL and a clear question: is this page actually indexed?

A quick first check is to use google search with:

site:yourdomain.com/example-page/

If Google returns zero results, the page may not be indexed. This is not a perfect diagnostic tool, but it is useful for spotting missing pages quickly.

Next, use Search Console. Go to the Page indexing report under Pages > Indexing. This shows total indexed pages, total non-indexed URLs, and the reason groups behind them. Patterns matter. Ten old tag archives excluded is rarely urgent. Thirty important pages listed as discovered currently not indexed is worth investigating.

For a single page, use the URL Inspection tool:

1. Paste the exact live URL.

2. Check whether it says “URL is on Google” or “URL is not on Google”.

3. Open the page indexing details.

4. Review crawl status, indexing status, canonical url, sitemap discovery, and any indexing errors.

5. If the url inspection tool shows old information, click “Test live URL” to check the current page, not just the last stored crawl.

This matters after WordPress changes. If you removed a noindex setting this morning, the historic report may still show the old problem. The live test helps you confirm whether the current output is now clean.

To diagnose indexing issues, use Google Search Console to inspect the URL and check for any noindex tags, canonical issues, or crawl blocks that may prevent indexing. The URL Inspection Tool in Google Search Console gives insight into why a specific page isn’t showing up in search results.

Also check your sitemap. A well-structured sitemap is essential for helping Google discover and index content; if the sitemap is incorrect or outdated, important URLs may be missed during crawling. A well-structured sitemap helps search engines efficiently discover and index your content, acting as a roadmap for important pages that might otherwise be missed during standard crawling.

Sitemaps should include all key pages of a website to ensure that search engines can crawl and index them effectively; missing important pages in the sitemap can lead to them being overlooked by Google. Submitting or resubmitting an updated sitemap in Google Search Console can help ensure that search engines are aware of new or modified content, facilitating quicker indexing of those pages. In Search Console, inspect the sitemap url and confirm it contains the URLs you actually want indexed.

Step 2 – Rule out basic WordPress and hosting misconfigurations

Many owner-led service sites are not held back by obscure SEO theory. They are held back by one global WordPress setting, a plugin default, or a hosting rule that was never cleaned up after launch.

Start with WordPress Settings > Reading. The option “Discourage search engines from indexing this site” should be unchecked on any live site. If it is checked, WordPress can send signals that tell search engine crawlers not to index the site. This often happens when a staging site is pushed live and the development setting comes with it.

Then check your seo plugin. Yoast, Rank Math, SEOPress, and All in One SEO all allow page-by-page indexation controls, which might accidentally be set to “noindex”. SEO plugins allow page-by-page indexation controls, which might accidentally be set to “noindex”. They also provide global settings for post types and taxonomies. Confirm that core WordPress pages and posts are set to index unless you have a deliberate reason not to.

Check for maintenance mode or coming-soon plugins. Some return non-200 responses, apply noindex, or show a temporary page to search engine bots while logged-in users see the real site. If the site is live, disable these tools or configure them properly.

Finally, check hosting, firewall, CDN, and security rules. Cloudflare, WordPress security plugins, and server-level firewalls can block Googlebot by IP, user agent, or rate limit. In Search Console this may appear as blocked by robots.txt, repeated 403 responses, server errors, or crawl failures. If logs include odd references such as user agent provided credentials, get your host or developer to review how bots are being authenticated or challenged.

Common technical barriers that prevent Google from indexing content include incorrect robots.txt configurations, noindex meta tags, and server errors. Common WordPress indexing issues stem from accidental “noindex” directives, blocked URLs in robots.txt, or low-quality content.

Step 3 – Diagnose common Google indexing issue types in GSC

Search Console is more useful when you understand what each category normally means on a WordPress site.

Search Console issue	What it usually means	How urgent is it?
Discovered – currently not indexed	Google knows the URL exists but has not crawled or indexed it yet	Medium to high for key pages
Crawled – currently not indexed	Google visited the page but chose not to index it	High if it affects commercial pages
Alternate page with proper canonical tag	Google found a duplicate or variant and accepted the canonical	Usually fine if intentional
Duplicate without user-selected canonical	Google found similar URLs but no clear preferred version	Medium to high
Blocked by robots.txt	Crawling is blocked by the robots txt file	High for public pages
URL marked noindex	A directive tells Google not to index the page	High if accidental
Server error (5xx)	Google could not access the page reliably	High

The discovered currently not indexed status often points to weak crawl priority. On a small site, this may mean poor internal linking, low authority, or pages that are not clearly connected to the main site structure. On larger WordPress sites, it can also reflect crawl budget pressure.

“Crawled – currently not indexed” is different. If Google has visited a page but isn’t adding it to the index, it’s often a content-related issue. Pages that are crawled but not indexed may indicate issues such as low-quality content, duplicate content, or technical barriers that prevent Google from processing them effectively.

Content quality is a major factor in whether Google decides to index a page, with low-quality content being the most likely to be ignored. Google’s algorithms prioritize content that is unique, valuable, and easy to discover, which means that pages with thin or duplicated content are less likely to be indexed.

“Alternate page with proper canonical tag” is not always a problem. WordPress often creates alternate pages through tags, categories, pagination, tracking parameters, and filtered URLs. If the proper canonical tag points to the preferred URL, those alternate pages can be safely excluded.

The more concerning categories are “Duplicate without user-selected canonical” and “Duplicate, Google chose different canonical than user”. These often come from inconsistent canonical tags, multiple pages using near-identical templates, or URL parameters that confuse google.

Step 4 – Fix hard technical blockers: noindex, robots.txt, HTTP and canonical issues

Hard blockers come first. There is little value rewriting copy or debating crawl budget if Google is being told not to crawl or not to index the page.

Technical barriers such as incorrect robots.txt configurations, noindex tags, and wrong canonical URLs are common reasons why Google fails to index content, even if the content is high-quality. Common reasons for Google not indexing a page include the presence of a ‘noindex’ tag, blocks in the robots.txt file, incorrect canonical tags, and server errors.

Remove unintended noindex tags in WordPress

A noindex tag instructs Google not to index a page, meaning if this tag is present, Google will skip indexing that page entirely. In HTML it commonly looks like this:

<meta name=”robots” content=”noindex”>

A noindex meta tag is a directive, not a suggestion. If it is present on a service page, Google should exclude that page from the Google index.

In WordPress, noindex can be applied in several places:

• page-level SEO settings;

• global post type settings;

• category, tag, author, or date archive settings;

• theme templates;

• header scripts;

• server headers such as X-Robots-Tag.

Check a representative sample: homepage, main service page, blog post, category archive, case study, and any lead-generation landing page. They should normally be “index, follow” unless there is a deliberate reason to exclude them.

Then view the page source and search for “noindex”. If you changed plugin settings, clear WordPress cache, server cache, and CDN cache before testing again. After fixing indexing issues, it is important to request reindexing in Google Search Console to prompt Google to crawl the updated pages again. Use “Test live URL” first, then request indexing only when the noindex tag is gone.

Fix robots.txt rules that block important URLs

The robots.txt file controls which parts of a website Google can crawl; if important pages are blocked here, they will not be indexed by Google.

You can view the live txt file at:

https://yourdomain.com/robots.txt

A normal WordPress robots file may block admin areas while allowing public content. A risky one may include:

Disallow: /

That blocks the entire site. Another common mistake is blocking /wp-content/, which can prevent Google from fetching CSS, JavaScript, images, and other resources needed to render the page properly.

For most service sites, sensible rules might block:

Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=

Risky rules include blocking service folders, location folders, case studies, or dynamic page requests that produce useful public content. If Search Console reports a blocked page, inspect the issue details page, edit the robots file through your SEO plugin or server, and retest the URL. You want “Crawl allowed? Yes” for public website pages.

Some exclusions are fine. Login pages, cart utility URLs, and internal search pages do not usually need indexing. But txt blocking on service, location, or article URLs should be treated as a priority.

Correct incorrect canonical tags and URL versions

Canonical tags indicate to Google which version of a page should be indexed; if a canonical tag points to the wrong page, Google may ignore the intended page for indexing.

For example, these may all show the same page:

/services/plumbing/
/services/plumbing/?utm_source=ad
http://www.example.com/services/plumbing/
https://example.com/services/plumbing/

The canonical tag should normally point to the preferred live version:

<link rel=”canonical” href=”https://example.com/services/plumbing/” />

Incorrect canonical tags often appear after migrations. A staging site goes live, but canonicals still point to staging.example.com. Another common issue is when the theme and SEO plugin both output a canonical tag, creating conflicting signals.

Use the URL Inspection tool’s rendered HTML view and compare Google-selected canonical with user-declared canonical. If a url google selected is not the one you intended, check internal links, redirects, sitemap entries, and canonical output. Disable duplicate canonical output so one system controls it.

A canonical tag is a strong signal, but Google may override it when other signals conflict. Incorrect canonical tags can collapse multiple pages into the same page, especially where templates are too similar. Clean the canonical output, update internal links pointing to the correct canonical page, and give Google a few recrawls.

Resolve redirect, 404 and server (5xx) issues that break indexing

Google cannot index a page reliably if it does not return a stable 200 status. Redirect errors, 404s, and 5xx failures need attention before content work.

Test key URLs with browser developer tools, curl, or an HTTP status checker. A clean setup should usually be:

1. old URL returns one 301 redirect if needed;

2. redirect urls point directly to the final URL;

3. final URL returns 200;

4. canonical matches the final URL.

Common WordPress causes include:

• old HTTP to HTTPS redirects;

• www and non-www confusion;

• redirect chain problems from legacy plugins;

• redirect managers sending search engine bots in loops;

• deleted pages with no replacement;

• heavy plugins causing timeouts.

A long redirect chain wastes crawl time and can affect indexing. Update menus, footer links, and body links so they point directly to the canonical URL, not through old redirect paths.

Persistent 5xx statuses usually point to hosting constraints, database issues, plugin conflicts, or excessive page loading. Technical issues such as slow-loading pages, server errors, and blocked resources can significantly hinder Google’s ability to crawl and index a website’s pages. If this is happening across the entire site, involve the host and stabilise PHP workers, database performance, caching, and timeouts.

RedShaw can also help turn this into a repeatable WordPress SEO checklist, so fixes are not limited to one URL or one rushed Search Console validation. For support with technical SEO cleanup, speak to Gareth about the site structure, templates, canonicals, and internal links behind the issue.

Step 5 – Tackle “Discovered / Crawled – currently not indexed” with content and structure fixes

Once hard blockers are removed, the remaining currently not indexed URLs often reflect Google’s assessment of value, uniqueness, and discoverability.

For smaller professional-service sites, improving a small set of key pages usually matters more than forcing every old blog post, tag page, or thin location page into the index. The practical aim is not “maximum indexed urls”. The aim is to make sure important pages that can generate enquiries are indexable, useful, and easy to find.

If technical settings are correct but pages still will not index, evaluate the site’s overall quality metrics, such as duplicate content and server performance.

Improve internal linking and site architecture in WordPress

Internal linking is crucial for indexing; orphan pages (pages without internal links) are less likely to be indexed because Google struggles to find and understand them.

This is common in WordPress. A service page gets built, published, added to the sitemap, and never linked from the menu, service hub, footer, or relevant blog posts. Google may discover it, but poor internal linking tells search engine crawlers it is not central to the site.

Make sure every important page is linked from at least one stable location:

• main navigation;

• service overview pages;

• location landing pages;

• footer links where appropriate;

• contextual links from relevant pages and blog posts;

• case studies and FAQs.

A clear hierarchy helps users and Google. For example:

Services > Commercial Electrical > Emergency Callouts

This structure gives Google a stronger sense of topic relationships. It also helps visitors find the next useful page, which supports enquiries rather than just search ranking.

Periodically crawl the site with an SEO tool to find orphan pages, very deep pages, and internal links pointing through redirects. Bring relevant pages closer to the homepage where they matter commercially. Better internal links can also support crawl budget on larger sites by helping Google prioritise the right sections.

Deal with duplicate content, thin templates, and alternate pages

WordPress can generate many overlapping web pages: category archives, tag pages, author archives, date archives, paginated lists, media attachment pages, search results, parameter URLs, and other pages that repeat the same content.

A deliberate indexation policy is better than letting everything through. For many service sites, it makes sense to index useful category archives but noindex tags, date archives, and internal search results. This keeps the site cleaner and reduces duplication bloat.

Service-area pages need particular care. If “Plumber in Leeds”, “Plumber in York”, and “Plumber in Harrogate” share 95% of the same copy, Google may decide that multiple pages do not deserve separate indexing. The same problem appears on professional-service sites with near-identical “accountants for dentists”, “accountants for solicitors”, and “accountants for consultants” pages.

To improve these pages, add genuinely specific value:

• local case studies;

• local testimonials;

• service constraints in that area;

• team or branch information;

• relevant regulations;

• specific FAQs;

• proof that the business actually serves that market.

Improving content quality by providing unique value, focusing on the main topic, and enhancing internal linking can signal to Google that a page is helpful and deserves to be indexed.

Not every exclusion is bad. Alternate pages with correct canonicals, print views, UTM versions, and filtered URLs can stay excluded when they point back to the main canonical page.

Upgrade content on key lead-generation pages

Google may crawl every URL on a small professional-service site but only index individual pages that look substantial, useful, and distinct.

Focus first on pages that drive enquiries:

• homepage;

• primary service pages;

• industry pages;

• location pages that matter commercially;

• strong guides and FAQs;

• case studies.

A strong lead-generation page usually has:

• a clear H1 and page purpose;

• specific service descriptions;

• practical process explanation;

• pricing guidance or ranges where suitable;

• FAQs based on real buyer questions;

• evidence such as case studies or examples;

• links to other relevant pages;

• a clear enquiry path.

This is where SEO and conversion work overlap. A page that is too thin for Google is often too thin for a buyer as well.

After a meaningful rewrite, use URL Inspection, test the live page, and request indexing. Do not repeatedly submit low-value URLs every day. Repeated submission does not turn weak content into useful content.

or drag and drop an image here

Step 6 – Manage crawl budget and performance on larger WordPress sites

Crawl budget is more relevant for larger WordPress builds: multi-location practices, franchises, publishers, WooCommerce sites, or blogs with hundreds or thousands of URLs.

In practical terms, crawl budget is how many URLs Google is likely to crawl on your domain within a period. It is influenced by site quality, update frequency, server performance, internal linking, and how much value Google sees in the site.

For a small service business with fewer than a few hundred pages, crawl budget is rarely the first explanation. For larger sites, these patterns can suggest crawl budget pressure:

• many URLs stuck in discovered currently not indexed;

• new content taking a long time to receive a google crawl;

• important pages crawled less often than low-value archive pages;

• parameter URLs consuming crawl activity;

• repeated server errors during crawling.

Prune or noindex low-value sections. Old tag archives, thin blog posts, empty categories, duplicate filters, and parameter-heavy pages can waste crawl attention. This is not about hiding problems. It is about making the indexable set smaller, clearer, and more valuable.

Performance also matters. Heavy page builders, unoptimised images, slow hosting, excessive plugins, and unstable caching can make Googlebot’s work harder. Better hosting, sensible caching, fewer plugin conflicts, and cleaner templates can improve the indexing process as well as user experience.

WordPress-specific pitfalls after migrations, redesigns, and staging pushes

A large share of Google indexing issues appear after a redesign, domain move, theme rebuild, or staging push. The causes are usually repeatable.

The common staging problem is simple: the staging site is blocked, then that blocked setup is copied to production. The live site inherits noindex settings, discourage search engines settings, robots restrictions, or blocked resources.

Another common migration issue is leftover staging URLs. They can sit inside:

• canonical tags;

• Open Graph tags;

• internal links;

• buttons;

• image paths;

• sitemap entries;

• database content;

• redirect rules.

If canonicals point to staging, Google may treat the live pages as duplicates of a non-live version. If internal links still point to the old domain, Google receives messy signals about which version is primary.

Run a careful search-and-replace at database level using a reliable migration tool or developer workflow. Replace staging and old-domain references with the correct live domain. Then flush plugin cache, server cache, and CDN cache.

Permalink changes are another common source of indexing problems. If an existing indexed URL is changed without a 301 redirect, Google may report “Not found (404)” and traffic can drop until redirects and internal links are corrected. Check existing indexed urls before changing URL structure, not after the damage is visible.

Plugins, themes, and JavaScript: when WordPress presentation breaks indexing

Modern WordPress builds often rely on page builders, animation libraries, tabbed content, accordions, sliders, filters, and JavaScript-loaded sections. Google can render JavaScript, but it is still possible to build a page that users see clearly while Google sees poorly.

Use the URL Inspection tool’s “View crawled page”, screenshot, and HTML views to compare what users see with what Googlebot sees. This is especially useful on Elementor, Divi, Avada, and block-based builds where key content may be loaded through scripts or hidden in interface components.

Watch for:

• service copy loaded only after user interaction;

• accordions that fail to render;

• CSS or JS blocked by robots.txt;

• security plugins returning 403 responses;

• caching plugins serving old noindex headers;

• multiple SEO plugins outputting competing metadata;

• themes adding duplicate canonicals.

If a page looks almost empty in the rendered HTML, Google may treat it as weak even if the front-end design looks polished.

The practical approach is systematic. On a staging copy, disable non-essential plugins, retest the affected URL, and re-enable plugins one by one. Do not troubleshoot ten variables at once. If a plugin conflict affects crawlability or indexability, document it, replace it, or change the configuration.

or drag and drop an image here

Prioritising fixes and monitoring indexing recovery

Not every non-indexed URL needs saving. A healthy WordPress SEO setup is not one where every possible URL is indexed. It is one where the right website pages are indexable, crawlable, useful, and connected to a clear seo strategy.

Use this priority order:

1. Fix sitewide blockers: discourage search engines, robots.txt mistakes, server errors, firewall blocks.

2. Fix template-level problems: noindex, incorrect canonical tags, duplicate metadata, broken sitemap output.

3. Fix core commercial pages: homepage, service pages, location pages, case studies, enquiry pages.

4. Improve internal linking and site structure.

5. Merge, rewrite, noindex, or remove thin or duplicate content.

6. Review long-tail posts, archives, tags, and minor duplicates.

In Search Console, use the indexing report filters to track the specific categories you fixed. If you remove a robots block, monitor the “URL blocked by robots.txt” group. If you clean noindex settings, monitor “Excluded by noindex”. After Google confirms the fix, you may be able to click validate fix in the issue details page for some grouped problems.

Expect delay. Indexing recovery can take a few days for important pages on active sites, and longer on newer or lower-authority domains. Check weekly, not hourly. Use request indexing for priority URLs after meaningful fixes, not as a substitute for proper implementation.

WordPress sites frequently encounter indexing issues that prevent pages from appearing on Google search results. The good news is that most indexing challenges are diagnosable with a calm process: inspect the exact URL, confirm whether Google can crawl it, check noindex and canonical signals, review content quality, then improve internal linking and performance.

A well-configured WordPress site, with clear templates, sensible plugin choices, clean sitemap output, stable hosting, and deliberate indexing decisions, should not need constant firefighting. If recurring indexing problems keep appearing across multiple pages, treat that as a signal to review the whole technical setup rather than patching individual symptoms.

If your key pages are still missing from Google after the basics are fixed, the next useful step is a focused WordPress SEO and technical audit: not a generic report, but a practical review of crawlability, indexation signals, content structure, internal links, performance, and the pages that actually need to generate enquiries.

If an indexing issue is blocking enquiries or a launch, RedShaw Consulting can audit the WordPress build, sitemap, canonicals, robots rules, internal linking, and page quality together. Get in touch if you want a practical fix list rather than another vague report.