Google indexing: status, barriers and follow-up

Check the exact URL in the correct Search Console property and first read the information about Google’s indexed version. Also open the address in a browser and note any redirect and the final URL. You need access to the website’s property. Paste the address into URL Inspection and open the result for that URL, not a similar address or another language version.

Why does indexing matter for SEO?

Indexing allows a page’s content to enter Google’s selection of search results; it does not guarantee visibility for a particular search or a particular ranking. An important service page absent from the index cannot contribute its content to that selection. Check that the intended page is included before evaluating its rankings. Focus on important canonical pages, rather than getting every filter URL or duplicate indexed. Google usually discovers pages automatically; a manual request is not a required step for every new page. Google explains how the index is used to select search results.

How do you use URL Inspection step by step?

URL Inspection shows Google’s information about a specific address within the property you have opened. Have the complete page URL ready. Inspect each language version separately when it has its own URL. Google’s URL Inspection instructions.

1. Choose the correct Search Console property. Open the page in a browser and note any redirect; make sure you are inspecting the intended address.
2. Paste the complete page URL into the inspection field at the top and press Enter. Do not inspect only the homepage when the question concerns an article or service page.
3. Wait for Search Console to retrieve the index information and display the result. Read the status for the exact address you entered.

A message about retrieving data from Google’s index belongs to the inspection. It does not confirm that an indexing request has been submitted or that the page has been indexed again.

How do you distinguish index status from a live test result?

Index status describes Google’s recorded version; a live test examines the page available now and does not show whether a new version has already been indexed. Use this distinction when a change is more recent than the report’s last crawl.

Note the indexing status shown, the last crawl and the selected canonical where this information is available. Open the page indexing details to see what the tool has actually observed. Then choose the live URL test if you need to investigate a change that is not yet reflected in the indexed data. Google’s instructions for URL Inspection explain the difference between these sources of information and the test’s limitations.

Can a site search replace the Search Console check?

No. A site search is a supplementary check, not a complete inventory of Google’s index. An illustrative query is site:example.com. A missing address in those results is insufficient evidence that it is not indexed. Inspect the exact URL in Search Console; do not treat the site-result count as an exact count of indexed pages. Google explains the site operator’s limitations.

What do “Crawled – currently not indexed” and “Discovered – currently not indexed” mean?

“Crawled – currently not indexed” means that Google has fetched the page without indexing it. “Discovered – currently not indexed” means that the address is known but has not yet been fetched. Google’s page indexing documentation explains the statuses.

The status alone does not show that the text is poor or that the page should be removed. Investigate the specific address’s accessibility, content, links and intended role before deciding what to do.

Which statuses need action?

Act on a status when it conflicts with what that specific URL is supposed to do. An intentionally removed page does not need indexing, and an old address leading to the correct replacement does not need to appear as a separate page. Distinguish intended behaviour from an actual obstacle before changing settings.

The technical meanings are described in Google’s HTTP response documentation and the Page indexing report. The table supports a decision; it does not diagnose your website.

Robots.txt controls crawling and is not a reliable way to keep a URL out of search results. A noindex directive must be readable by the search engine to work as intended. Google explains the difference.

Do not block crawling while also assuming that Google has definitely seen a new noindex directive. Check the actual state.

Where can a noindex rule be set?

Noindex can appear in a page’s robots meta tag or in its HTTP response as X-Robots-Tag. Check both the delivered HTML and the response headers. Removing the rule in an administration field is insufficient if a template or server rule still sends it. Google does not support a noindex line in robots.txt. See Google’s noindex documentation.

Illustrative example: a new service page becomes accessible after testing but still inherits noindex from the test environment. First establish that the page should be public and searchable, fix the source sending the rule, then test the published address. Noindex is not access control that protects confidential information. Private test or client pages still need appropriate access protection, such as authentication.

Duplicates can be consolidated under a representative address, while page content is assessed as part of indexing. A distinct answer does not guarantee indexing. If two addresses show the same text, do not automatically write a third version. First assess whether the addresses are duplicates, language versions or genuinely different offerings. A canonical identifies a representative address; it does not turn two different customer needs into the same question.

A new page should also be reachable from relevant content on the website. Read about internal routes to pages.

How do you investigate an unexpected canonical?

Compare your intended address with Google’s selected address and check what both actually display. Is the content duplicated, or do the pages describe different services? Then check the addresses used by internal links, the sitemap and the page’s canonical. Google’s canonical guidance explains these signals; a stated preference is not an instruction guaranteed to be followed.

Illustrative example: an old address and a new address show the same guide. Document which should be primary and align the signals around it. If the addresses instead describe two distinct offerings, investigate the content difference rather than hiding it by pointing both to the same canonical.

Document what has changed and check the status afterwards. Submitting the same request repeatedly is no substitute for resolving an access issue or improving the content.

How do you request indexing after a fix?

After a fix, an owner or full user can request indexing for an individual URL in Search Console’s URL Inspection tool. The action concerns the inspected address. An already indexed page may need a new crawl after a change; being indexed is not a reason to submit it repeatedly.

1. Inspect the exact URL using an account with owner or full-user permissions. Check that the result page shows the intended address.
2. Read any reported obstacles. If the page was fixed after the last crawl, run a live test and check the published version before proceeding.
3. Select Request indexing on the inspection result when you want a new crawl of the accessible page.
4. Wait for the quick test. If the tool finds that the page cannot be indexed, fix the obstacle; more clicks on the same request will not resolve it.
5. Record the date and any confirmation that the request was received. Then monitor index status separately. Confirmation does not mean the page has already been added to the index.

Google limits the number of requests. Submitting the same URL repeatedly does not make crawling faster, and a request does not guarantee indexing. Google’s guidance on requesting a recrawl.

Illustrative example: a page intended to be public had a noindex directive. Once the directive has been changed, the live test needs to be able to read the new version. Google’s noindex documentation explains what the directive does and how to check it. An authorised user can then request indexing. Passing an access test still does not mean that the page is already indexed. Record the date of the change and compare it with subsequent indexing information.

How do you submit a sitemap to Google Search Console?

An owner of the Search Console property can submit the address of a published sitemap through the Sitemaps report. Acceptance of the file does not guarantee indexing of its pages. A sitemap lists addresses for Google to discover. It is useful for many new or updated URLs and complements relevant internal links.

1. Find the actual sitemap address in your publishing system or its documentation. Examples include https://example.com/sitemap.xml and https://example.com/sitemap_index.xml, but the filename must match your website.
2. Check that the file exists and is accessible to Googlebot without a login. Verify that it lists the intended canonical addresses of pages you want in search results.
3. Open the correct property with owner permissions and choose the Sitemaps report. Enter the sitemap file’s address in the new-sitemap field and submit it.
4. Read the report result. If fetching or processing fails, open the error details and fix the file or its accessibility.
5. Later, check indexing of the important pages. Successful reading of the sitemap file is a different result from every listed page being crawled and indexed.

Submit the file URL, not just the domain’s homepage. If the field already displays a URL prefix, the part you enter and that prefix must form the exact sitemap address without duplicating the domain. The addresses above are examples, not a statement of where your own file is located. Google describes submission, owner permissions and error statuses.

A sitemap can help Google discover pages but does not replace accessibility, indexable content or internal linking. Choose the URLs intended to represent the content, not every technical variation. Google’s instructions for building a sitemap and the limits of what a sitemap guarantees.

How long does a recrawl take?

According to Google, a recrawl can take from a few days to a few weeks. This is a timeframe for crawling, not a promise of when the page will be indexed or gain a ranking. Monitor the status in Search Console; a request does not guarantee inclusion in search results. The same Google guidance on recrawling states this limitation.

If terms such as fetching and rendering are unfamiliar, the explanation of the stages in the search process provides the background. You can then use this guide to check an actual URL without guessing from a single status.

For a confirmed technical problem, see SOVRA Digital’s technical audit.

What should the follow-up record contain?

A useful follow-up separates the completed fix from a later observed result. Keep evidence for the specific URL so the next check can be compared with the same page:

• Before: intended task, reported status, last crawl and selected canonical.
• Change: what was fixed, in which data source and when it was published.
• Immediate check: server response, directives and content present in the published version.
• Later check: new crawl date, current indexing status and any canonical change.
• Conclusion: what the evidence establishes and what remains unknown.

Google’s URL Inspection tool distinguishes information about the indexed version from a current test. If the report still uses data from before the fix, it does not establish that the new version was rejected. A page subsequently being indexed does not establish that it receives traffic or a particular position.