Google Cache Checker

Google Cache Checker is a free tool that checks a URL for a Google cached copy and reports when the URL is not cached.

What does a Google cache check actually tell you?

A Google cache check looks for evidence that Google has stored a retrievable copy of a particular web page. A cached copy was historically a snapshot taken when Google last crawled the page, rather than a live version served by the website.

Caching and indexing are different. An indexed URL may be eligible to appear in Google Search, while a cached URL had a stored snapshot that people could open. A page can be indexed without having a publicly accessible cached copy, so a negative cache result does not prove that Google has removed the page from its index.

Google retired its public cached-page links in 2024. As a result, cache availability is no longer a dependable way to assess indexing. For a site you control, Google Search Console's URL Inspection tool gives more relevant information about discovery, crawling, canonical selection and indexing.

How do I read the result?

The result means that the check did not find a cached copy for the submitted URL. This tool returns one result field:

• This URL is not cached. No Google cached copy was identified for that exact submitted address. It does not confirm that the page is absent from search results, blocked from crawling or technically faulty.

It concerns the URL entered, including its hostname, path and parameters. These addresses may represent different resources:

• https://www.example.co.uk/guide
• https://example.co.uk/guide
• https://www.example.co.uk/guide/
• https://www.example.co.uk/guide?source=email

A website may redirect some or all of them to one preferred address. If you are unsure which version Google reaches, check the final destination with a URL redirect checker and inspect that destination in Search Console.

When would I run this check?

You would run this check when investigating an old search snapshot or trying to understand why a particular URL does not appear to have a cached copy. The cache result cannot establish whether the URL is indexed.

1. A page has recently changed. You may want to know whether an older copy is still available. A negative result means this check did not identify one, but search snippets can still reflect information collected during an earlier crawl.
2. A new page is missing from search. Check the exact published URL, then use Search Console to see whether Google discovered and indexed it. Also confirm that the page returns a successful HTTP status and is not excluded by a noindex directive.
3. A site has moved to a new domain or URL structure. Check redirects from the former address to the new one. Google may take time to crawl the redirects, select canonical URLs and update search results, regardless of whether a cached copy exists.

DNS resolution failures, emails not arriving and browser certificate warnings concern DNS, mail configuration or TLS certificates. A Website hosting checker may help identify where a functioning site is hosted, but it does not diagnose every DNS or certificate fault.

Caching, indexing and propagation delays

A correct result can look wrong when several independent caches and update cycles are involved. Google chooses when to revisit pages, and a change on your server does not appear in search immediately. Search snippets, canonical information and indexed content may update at different times.

DNS changes have their own delay. Recursive DNS resolvers retain records for their time to live, commonly called TTL, so some visitors may reach an old server while others reach the new one. Browser caches, reverse proxies and content delivery networks can also retain earlier files. None of these caches is the same as a Google cached page.

If a recently edited page still looks old, open the live URL, inspect its HTTP response and clear or bypass any cache you control. Then check the URL in Search Console. Repeated cache checks cannot make Google recrawl a page sooner.

How are URLs with spaces or non-ASCII characters handled?

The submitted address is URL-encoded on the server using PHP's urlencode operation. It applies the application/x-www-form-urlencoded convention: spaces become plus signs and other non-safe bytes are percent-encoded.

For example, the text https://www.example.co.uk/search?q=cream tea is encoded as https%3A%2F%2Fwww.example.co.uk%2Fsearch%3Fq%3Dcream+tea. Under this encoding, the space becomes a plus sign. An accented UTF-8 value such as café becomes caf%C3%A9.

Numbers are accepted by the encoding format without alteration, while punctuation such as slashes, question marks and equals signs is encoded. An internationalised domain name may contain an IDNA A-label, which uses the xn-- prefix and Punycode for that label.

This tool's server-side urlencode processing does not repair an invalid or incomplete URL. An empty value has no page to check, and a very long address may exceed limits elsewhere in the request path. Copy the address from the browser rather than typing it from memory.

Frequently asked questions

Does a negative cache result mean my page has been deindexed?

No. Public cache availability and search indexing are separate, and Google no longer provides its former cached-page links. Check the URL in Google Search Console or search for a distinctive sentence from the page, while remembering that ordinary search queries are not a complete index report.

Should I include tracking parameters in the URL?

Use the clean canonical URL unless you specifically need to investigate a parameterised version. Parameters such as utm_source often identify campaign visits rather than separate content, and Google may consolidate them under a canonical URL.

Can I check a private or password-protected page?

A crawler generally cannot retrieve content that requires a login unless access has explicitly been provided, so such a page should not be expected to have a public search cache. The submitted URL travels to this tool's server over HTTPS for processing and is not stored, so do not include passwords, access tokens or other secrets in it.

Do URL fragments affect the page Google sees?

A fragment is the part after a hash sign, such as #delivery. Browsers normally do not send fragments in HTTP requests, so two ordinary URLs differing only by a fragment usually retrieve the same document. Check the address without the fragment when diagnosing the indexed page itself.

What should I check before requesting another crawl?

Confirm that the preferred URL loads without a redirect loop, returns a successful response, allows Googlebot to crawl it and does not contain an unintended noindex directive. Check that the href value of its link element with the canonical link type names the intended URL, then request indexing through Search Console if you manage the site.