How to Check Google Indexation for a URL

Before a page can appear in Google search results or generate organic traffic, it must be included in Google's index. Checking whether a specific URL is indexed is the foundational diagnostic step when verifying a new publication, auditing site migrations, or troubleshooting a page that is unexpectedly missing from search results.

There are two distinct ways to verify this status, depending on the level of access you have to a domain. Google Search Console provides the definitive, technical truth about a URL's indexation state, including specific crawl decisions and diagnostic errors. In contrast, manual search operators like the "site:" command offer a quick, directional check for users without verified property access, though these public searches are an approximation and can occasionally produce false negatives.

It is important to recognize that indexation is strictly a prerequisite for search visibility, not a guarantee of ranking performance. Confirming that a URL is indexed simply means Google has successfully crawled, parsed, and stored the page, making it eligible to compete algorithmically for relevant queries.

Using the GSC URL inspection tool for definitive status

To obtain an authoritative answer regarding a page's indexation, use the URL Inspection Tool within Google Search Console. Because this tool queries Google's internal index database directly, it serves as the single source of truth for property owners. To begin a check, paste the complete URL into the primary search bar at the top of the Search Console interface. The submission must exactly match the live URL, including the correct protocol and any subdomains.

After retrieving the data, the tool displays a top-level presence state. The three primary outcomes you will encounter are:

• URL is on Google: The page has been successfully crawled, processed, and stored in the index. It is eligible to appear in search results.
• URL is not on Google: The page is excluded from the index and cannot appear in search results. The tool will provide a specific coverage reason explaining why the system rejected or delayed the URL.
• Page is indexed but has issues: The page is included in the index and can surface in search, but Google detected non-critical errors. These issues typically relate to mobile usability failures, HTTPS evaluation errors, or invalid structured data that prevents the page from qualifying for rich results.

When reviewing these results, it is necessary to distinguish between the default index status view and the Test Live URL function. The initial inspection report is entirely retrospective. It displays the page state exactly as Googlebot encountered it during the last successful crawl date, which is recorded in the Page Fetch section of the report. If you have modified the page content, updated canonical tags, or removed a noindex directive since that timestamp, the default index view will not reflect those updates.

To evaluate the real-time state of the page, you must run a Live URL Test. This function triggers an immediate fetch by Googlebot, allowing you to verify if recent technical fixes resolve the issues reported in the historical index view. While a successful live test confirms the page is currently accessible and capable of being indexed, it does not instantly overwrite the main index database. The page must still wait for a natural crawl and indexing cycle before the official index status updates to reflect the live conditions.

Interpreting common 'not indexed' statuses

When the URL Inspection Tool reports that a page is not on Google, the Page Indexing section of the report provides a specific diagnostic reason. Understanding these statuses helps differentiate between technical crawl limitations, content evaluation decisions, and intended deduplication.

Discovered - currently not indexed

This status indicates that Google knows the URL exists, typically having found it via an XML sitemap or an internal link, but has not yet crawled the page. The system postponed the fetch.

A delayed fetch often occurs if Google calculates that requesting the page might overload the server, or if the site's immediate crawl capacity has been exhausted. The URL remains in the known queue and may be crawled in a future cycle. No immediate technical intervention is required to make the page accessible, though consistently seeing this status across many new pages can signal server performance limits or a crawl budget constraint.

Crawled - currently not indexed

This status confirms that Googlebot successfully accessed and loaded the URL, but the system declined to add the page to the index. Unlike the "Discovered" status, there are no crawl blocks or server capacity issues preventing access.

Exclusion after a successful crawl frequently indicates that the indexing system evaluated the parsed content and deemed it unnecessary to include in search results. This commonly happens with thin content, paginated archives, auto-generated pages, or items that do not offer sufficient unique value. Resolving this status typically requires modifying the page content to improve its standalone utility rather than fixing technical accessibility.

Canonicalization decisions

Many URLs are excluded from the index intentionally due to duplication. To diagnose whether a page was filtered as a duplicate, review the canonical decision report located at the bottom of the Page Indexing card in the URL Inspection Tool. This area lists two distinct fields:

• User-declared canonical: The URL specified by the site owner via a rel="canonical" link tag or HTTP header.
• Google-selected canonical: The URL the indexing system ultimately chose as the primary, authoritative version of the content.

If the Google-selected canonical differs from the URL you are inspecting, the inspected URL will be designated with a status such as "Alternate page with proper canonical tag" or "Duplicate without user-selected canonical" and will remain unindexed. This is the intended behavior for tracking URLs, session IDs, or alternative category paths that resolve to identical content.

However, if a page is meant to be indexed independently but Google selects a different URL as the canonical, it means the system considers the two pages too similar to warrant separate index entries. To secure indexation for the inspected URL, the content must be differentiated enough that the system no longer consolidates it with the Google-selected canonical.

Quick manual checks with the site: Operator

When access to Google Search Console is unavailable, manual search operators offer a fast way to check indexation status directly from the search bar. The most direct method is appending the target URL to the site: operator, formatting the query as site:example.com/specific-page-url . Alternatively, searching for the exact URL enclosed in quotation marks achieves a similar targeted lookup.

If the search engine returns a standard search result snippet matching the URL, the page is currently stored in the index. This confirms indexation without requiring verified property ownership.

However, manual search queries carry significant reliability limitations. The site: operator is designed to return a sample or approximation of indexed content rather than an exhaustive database inventory. It frequently drops valid, indexed URLs from its output, particularly when querying deep pages, newly published content, or URLs on very large domains.

Because of this filtering behavior, a manual search often produces false negatives. If a site: query yields no results, it only indicates that the page did not surface for that specific command; it does not constitute definitive proof of deindexation.

When manual search results conflict with the data provided by Google Search Console, the Search Console status remains the authoritative record. If a page fails to appear for a site: search but is marked as indexed in the URL Inspection Tool, the page is indexed and remains eligible to appear in standard search queries.

Verifying indexation of JavaScript-Rendered content

Even when a URL is officially indexed, pages relying on client-side JavaScript introduce a specific edge case: the base HTML document is in the index, but the critical content generated by the JavaScript may be missing. This discrepancy occurs because Google processes JavaScript in a separate rendering queue. When Googlebot initially crawls a page, it indexes the raw HTML response. The execution of JavaScript, which often fetches the primary text or product details, is typically deferred. This creates a delay between the URL itself being indexed and the fully rendered content becoming searchable.

To verify if the client-side content has successfully entered the index, select a unique text snippet from the page that only exists after the scripts execute. Search for this exact string on Google enclosed in quotation marks. If the search returns the target URL, the rendered content has been processed and indexed. If the page does not appear, Google may currently only have the initial, pre-rendered HTML framework stored in its database.

For a technical verification of what Google's rendering engine can process, use the URL Inspection Tool in Google Search Console. After running a Live URL test, open the View Tested Page panel. Navigate to the HTML tab, which displays the Document Object Model after Googlebot has executed the page scripts.

Search this code view for the specific dynamic content. If the target text is present in the tested HTML but fails the manual snippet search, the page is likely still waiting in the rendering queue to be fully indexed. If the content is entirely missing from the View Tested Page HTML, Googlebot is likely encountering script errors, timeouts, or blocked rendering resources, meaning the client-side content will remain unindexed until the underlying technical issue is resolved.

Checking URLs in bulk with the URL inspection API

While the manual URL Inspection Tool handles single-page checks, auditing large site migrations, new category launches, or programmatic rollouts requires checking multiple pages simultaneously. Google provides the URL Inspection API to automate this process, allowing users to query the index status of exact URLs programmatically.

It is important to differentiate this specific on-demand querying from the broader Page Indexing report in Search Console. The standard indexing report assesses site-wide crawling and indexing trends over time, categorizing pages based on Google's historical crawl data. It does not allow users to input a custom list of specific URLs for immediate verification. The API bridges this gap by providing immediate, URL-level lookups for exact lists, returning the same granular data found in a manual Search Console inspection.

Accessing the API at scale requires bulk automation. This can be achieved through custom scripts using languages like Python or Node.js to interact with Google API client libraries. Alternatively, many third-party SEO crawlers and specialized spreadsheet add-ons integrate directly with the API. These tools allow users to authenticate their Search Console account, upload a targeted list of URLs, and pull the index status, Google-selected canonical, and last crawl time into a single dataset.

Using the API introduces strict rate limits. Google enforces a fixed quota per Search Console property, restricting lookups to 2,000 queries per day. There are also smaller query limits per minute tied to the Google Cloud project making the request. Because of these strict constraints, the API is not designed for auditing an entire enterprise website at once. It is most effective when applied to targeted subsets of URLs, such as newly published content, priority product pages, or specific URL clusters suspected of encountering indexing anomalies.

Once the bulk data is retrieved, the API response details the current index state for each submitted URL. By cross-referencing this output with an internal URL inventory, an XML sitemap, or a recent site crawl, practitioners can isolate the exact pages missing from the index and prioritize technical troubleshooting based on the specific exclusion reasons provided by the API.