WordPress SEO Checklist 2026: Fix Pages Not Indexed by Google

If a WordPress page does not appear in Google, publishing another article is not the first move. Search indexing has a sequence: Google must discover the URL, fetch it, understand whether it is indexable, select a canonical version and decide whether to keep it in the index. A healthy-looking page can still be blocked by a robots directive, an incorrect canonical or a server response that search crawlers cannot access.

Step 1: Start with URL Inspection in Search Console

Inspect the exact affected URL in Google Search Console. Check whether Google has seen it, the last crawl date, the detected canonical and any blocking reason. “Discovered – currently not indexed,” “Crawled – currently not indexed,” and “Excluded by noindex” describe different problems. Do not apply the same fix to all three. A brand-new page can also need time before it is indexed.

• Check the live URL rather than only the saved indexing report.
• Inspect the user-declared and Google-selected canonical values.
• Confirm the page is reachable without a session or login.
• Check that the visible content is substantial and distinct from neighboring pages.

Step 2: Verify WordPress visibility settings

WordPress has a site-level setting that can ask search engines not to index the site. It is convenient on staging and disastrous when copied to production. In Settings → Reading, make sure “Discourage search engines from indexing this site” is not enabled unintentionally. With WP-CLI, the related option is blog_public; 1 generally indicates public visibility. A search engine can still choose whether to index a URL.

wp option get blog_public
# Expected for a public site: 1
# Inspect the WordPress setting before changing anything.

Changing the reading option will not resolve a separate noindex header, HTTP authentication wall or SEO plugin directive. Search crawlers can receive different responses from logged-in users if a CDN, firewall or bot rule is misconfigured. A live inspection is more informative than checking the editor preview.

Step 3: Inspect HTTP status, redirects and robots rules

A canonical page should normally return HTTP 200. Redirect loops, chains, 404 pages and temporary errors complicate crawling. Inspect the final URL and the HTML head. A robots.txt disallow rule influences crawling; a noindex meta directive controls indexing when the page can be fetched. Blocking a URL in robots.txt can prevent the crawler from seeing its noindex directive, so do not use both indiscriminately.

curl -sS -o /dev/null -w "HTTP %{http_code} | %{url_effective}\n" -L https://example.com/target-page/
curl -sSL https://example.com/target-page/ | grep -iE "noindex|canonical|robots" | head -n 20
curl -sSL https://example.com/robots.txt | head -n 40

The grep output is an initial diagnostic, not a full HTML parser. Headers can also contain an X-Robots-Tag directive, so inspect them separately. If your page requires JavaScript to render the primary content, compare the server-delivered HTML with the rendered page Google sees. Aim to make essential content and metadata available without relying entirely on a complex client-side hydration path.

Step 4: Correct canonical URL conflicts

A canonical link is a signal about the preferred URL among duplicates, not a command to index a page. Typical WordPress problems include http and https variants, www and non-www, trailing slash disagreements, parameter-based duplicates and multiple SEO plugins generating conflicting tags. Choose one preferred public address and ensure redirects, internal links, XML sitemaps and canonical tags agree.

<link rel="canonical" href="https://example.com/guide/" />

The markup above shows what the final HTML should contain. Do not paste a second canonical tag into functions.php if an SEO plugin or WordPress core already generates one. Instead correct the source of the wrong canonical and validate the rendered output. Google may still choose a different canonical if the pages have different content or inconsistent signals.

Step 5: Test the XML sitemap and sitemap coverage

WordPress core commonly exposes wp-sitemap.xml, while SEO plugins may generate their own sitemap index. Use the one actively configured for your site. An XML sitemap lists canonical URLs you want discovered; it does not force indexing. Exclude intentionally private, redirected, noindex and duplicate pages. Then submit or refresh the sitemap reference in Search Console and inspect its reported errors.

curl -sSI https://example.com/wp-sitemap.xml
curl -sSL https://example.com/wp-sitemap.xml | head -n 35
# If your SEO plugin provides a different sitemap URL,
# use the one configured in that plugin.

Do not submit both core and plugin sitemaps simply because they exist. Compare actual sitemap entries with the canonical pages you want visible. A sitemap full of expired URLs, redirects or duplicate parameters increases diagnostic noise rather than making the site more discoverable.

Step 6: Fix internal linking and content cannibalization

Search engines discover many pages by following ordinary HTML links. A page that appears only in a JavaScript search result or has no contextual links may be difficult to discover and understand. Link from relevant existing pages using descriptive anchors that explain the relationship. Avoid creating several nearly identical posts aimed at the same keyword intent: decide which page is the primary guide and give supporting pages narrower jobs.

For example, a broad WordPress performance page can point readers to slow wp-admin troubleshooting, while a commerce-specific page can link to WooCommerce checkout fixes. These are different problems, so internal links add context without forcing them to compete for exactly the same query.

Step 7: Use structured data only when it matches the page

Article, BreadcrumbList and Product schema can improve machine understanding when they accurately describe visible content. Structured data does not override a noindex directive or guarantee a rich result. Avoid fabricated reviews, unsupported FAQ markup or duplicate conflicting schema generated by multiple plugins. Check the generated JSON-LD in the page source and validate eligible types with Google’s Rich Results Test.

Step 8: Handle search pages and thin archives intentionally

Internal search result pages and large sets of low-value filtered URLs can waste crawl attention. WordPress provides a wp_robots filter to add directives based on context. The following site-plugin snippet marks internal search result pages noindex. It does not block crawler access, and it leaves normal posts and pages alone. Check existing SEO plugin behavior first so you do not create conflicting directives.

add_filter( 'wp_robots', function ( array $robots ): array {
    if ( is_search() ) {
        unset( $robots['index'] );
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }
    return $robots;
} );

Put custom hooks in a site-specific plugin, and run the rendered-page check afterward. Blocking archive pages indiscriminately can remove useful category navigation from search; the decision depends on content quality and site structure.

Step 9: Improve the page before requesting indexing again

A technically indexable URL can still be unhelpful. Give it a unique title that accurately describes the question answered, a clear introduction, useful examples, and a logical heading structure. Show original screenshots or code where they help, but do not publish hundreds of near-duplicate pages by swapping keywords. Update outdated material when the underlying WordPress version or plugin behavior changes.

• HTTP 200 and no unintended noindex in HTML or headers.
• One consistent canonical matching redirects, links and sitemap entries.
• A working XML sitemap containing the desired canonical URL.
• A contextual internal link from at least one relevant indexed page.
• Useful, differentiated content that answers the actual search intent.
• Search Console URL Inspection used after fixes, with realistic expectations about crawl timing.

Frequently asked questions

Why is my page crawled but not indexed?

Google may crawl a page and decline to index it because of duplication, perceived content quality or other signals. Verify the selected canonical and technical eligibility first. If those are correct, improve differentiation and usefulness instead of repeatedly resubmitting unchanged content.

Does an XML sitemap guarantee indexing?

No. A sitemap helps discovery and conveys preferred canonical URLs. It is not an approval queue. Google still evaluates the fetched page and its signals.

Should I use two WordPress SEO plugins?

Usually not for overlapping title, canonical, schema and sitemap output. Pick clear ownership and inspect the actual rendered page. For architectural context, see Headless WordPress vs Custom Theme.