If your site does not appear for a search, first check one exact public URL in Search Console. A page that is not indexed needs a different investigation from an indexed page ranking below the results you inspected.
Use the reported state to review accessibility, indexing controls, discovery and the page’s distinct usefulness.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Reported state | Investigation | Next check |
|---|---|---|
| Fetch or crawl error | Public accessibility | Status and timed server logs. |
| Excluded by noindex | Intended page visibility | Page or SEO settings. |
| Different canonical selected | Preferred version | Canonical, links and sitemap agreement. |
| Crawled but not indexed | Distinct content and duplication | Reader value and competing versions. |
| Indexed but few impressions | Relevance and query demand | Performance report for the actual URL. |
Check the exact URL in Search Console
- Select the property covering the current address.
- Inspect the exact canonical public URL.
- Compare the stored indexing result with the live test.
- Record the reported reason before changing content or settings.
Make sure you are using the property for the intended domain, then inspect the page’s current public address. A domain property and a URL-prefix property cover different scopes, so a report for an old hostname may not describe the new page.
The indexed result and a live test answer different questions. The indexed result reflects Google’s stored information; the live test helps check the page’s current accessibility. A successful live test does not promise that the page will be indexed.
If Google selected another canonical URL, inspect that address too. Duplicate or moved pages may be represented by a different version in search. Decide which URL should be the preferred public page before changing signals.
Confirm that the public page is available
Open the page without an administrator session and verify that it shows the intended content. A draft preview, login-only page, or staging copy is not the same as a publicly available article.
Check the actual response if Search Console reports an error. A page that visually displays content but returns a server-error status can be treated differently from a normal successful response. Intermittent failures also matter: one successful visit does not rule out errors during Google’s fetch.
Our 404 guide and 503 guide help with those symptoms. The host can compare crawler requests with server and firewall logs.
Review crawling and indexing controls separately
Control distinction: robots.txt governs crawling; noindex governs indexing when the crawler can read it. Neither is a substitute for authentication on private information. Keep deliberate private and staging restrictions intact while reviewing a public article.
In WordPress, review the search-engine visibility setting and the SEO settings for the individual page. A production site can accidentally retain a staging noindex setting after launch.
A noindex directive asks supported search engines not to index the page. A robots.txt rule controls crawling. These are different controls: blocking the crawl can prevent Google from seeing a noindex directive on the page.
Keep intentional exclusions for private, duplicate, or low-value pages. Removing every restriction to increase a report count can expose content you never meant to publish. Review the purpose of the affected page before making it indexable.
Make the page discoverable
A useful internal link from a relevant public page helps visitors and crawlers find the content. An article that exists only at an unlinked address can be harder to discover than one placed naturally in the site’s navigation or topic structure.
Use the sitemap generated by your actual WordPress or SEO setup, and confirm that it lists the intended canonical URLs. A sitemap is a discovery aid, not a guarantee of indexing or ranking. Our sitemap guide covers errors with that file.
After a genuine correction, an indexing request for a small number of important pages can be appropriate. Repeating the same request does not make Google process it on demand. Keep the change and request date in your notes so later results can be compared meaningfully.
If the page was crawled but remains unindexed
Review whether it provides distinct, useful content. Several pages repeating nearly the same explanation may give Google little reason to select each one. A title change alone does not create a substantially different answer.
Check the main content as a visitor: does it answer the promised question, provide concrete detail, and avoid empty sections or placeholders? If a page is a duplicate of another version, align its links, canonical, and sitemap with the version you want used.
Security issues and manual actions have their own Search Console reports. Review those when the site’s symptoms point there, rather than assuming every missing result is a penalty.
If the page is indexed but hard to find
Use Search Console’s performance report to see the queries and pages receiving impressions. Ranking for a broad competitive phrase is a different challenge from getting a URL indexed. Improve the page’s relevance and usefulness for the reader it is meant to help.
Keep the evidence for each step: current accessibility, indexing controls, discovery links, and the reported state. Google’s noindex guidance, crawl troubleshooting documentation, and indexing FAQ explain the distinctions and the limits of submission requests.
Track the correction against the reported state
Record the URL, original state, concrete correction and request date if a recrawl was requested. Check later indexing and performance reports separately. Submission does not guarantee indexing, ranking or a particular completion time.