Google Index Checker

How the index check works

The checker asks Google directly, the same way you would by hand, and reads the results page. For each URL it runs a site: search for the page. A site: query matches a prefix, so for a section such as /blog Google often fills the first page with articles inside it and leaves the section itself out. When the page is not among the results, the checker also searches for the URL itself, and only reports “not indexed” when both searches miss it.

Every page gets one of four verdicts:

• In Google: the page itself was found by one of the two searches.
• Not in Google: neither search returned the page.
• Other URL in Google: Google returned the page’s canonical URL instead of the page, so it is indexing that one in its place.
• Search failed: Google could not be read this time. The rest of the check still runs, so retry the page later.

URLs are compared without the scheme, www., a trailing slash or tracking parameters, so https://www.example.com/page/ and example.com/page count as the same page.

Noindex, canonical and status in the same check

A page that is not in Google often tells Google to stay away itself. While the search runs, the checker opens the page in a real browser and reads what it says:

• HTTP status and redirects: the response code, and where the page ends up if it redirects. A page that answers through a bot-protection wall is marked as such instead of as an error.
• Noindex: the robots and googlebot meta tags, including none.
• Canonical: whether the canonical tag points at the page itself or at another URL.
• Indexable: the verdict from those three. A page is indexable when it answers 2xx on its own URL, has no noindex and is its own canonical.

The X-Robots-Tag response header and robots.txt are not read, so check them by hand when a page is indexable here but still missing from Google.

Page load time test: TTFB, FCP and Load

The same browser load that reads the tags also times the page. A slow page is a problem before it is an SEO problem: visitors leave, and a server that takes seconds to answer also slows Google’s crawl. Every check records:

• TTFB (time to first byte): how long the server takes to start answering. Mostly hosting, caching and backend work.
• FCP (First Contentful Paint): when the first text or image appears on screen.
• Load: when the page has finished loading, images, fonts and scripts included. Nothing is blocked to make it look faster.
• Size: the data transferred for the page and its resources.

The results table colours a value only when it needs attention:

The TTFB and FCP bands follow Google’s Web Vitals thresholds; Load uses the LCP ones. The page is loaded from a cloud browser, by default in London, so the numbers are one real visit from one place, not the average of your users. In Page Monitor, a reading much slower than the page’s previous one is loaded a second time and the faster run is kept, so one slow node does not count as a slow site. For real-user data and Lighthouse audits, see the PageSpeed and Core Web Vitals panels in SerpDino projects.

Index checker vs Search Console URL Inspection

Search Console is Google’s own answer and the place to ask Google to index a page. The checker answers a different question: what Google shows for the page right now, for any site, many pages at a time.

Page not indexed? What to check

1. Status. The page must answer 200 on its own URL. A 404, a 5xx or a redirect keeps it out of the index.
2. Noindex. Remove noindex from the meta robots tag, and check the X-Robots-Tag header in your server or CDN settings.
3. Canonical. The canonical should point at the page itself. A canonical to another URL asks Google to index that URL instead.
4. robots.txt. A disallowed page cannot be crawled, so Google cannot see its content.
5. Discovery. List the page in your XML sitemap and link to it from pages Google already indexes.
6. Content. When Search Console says “Crawled – currently not indexed”, Google saw the page and passed on it. Make it more useful and less like other pages on the site.
7. Ask Google. After fixing it, use Request indexing in URL Inspection, then check the page again over the next days.

Website performance monitoring: see the day it slowed down

One check shows today. Sites rarely break all at once: a release adds a heavy script, a cache stops working, the server starts taking a second longer, a page picks up a noindex or drops out of Google, and nobody notices until traffic falls. A Page Monitor project in SerpDino runs this same check on the pages you choose, on a schedule, and keeps every day, so you can point at the date things changed:

• Speed history per page: TTFB, FCP, Load and page weight for every day, side by side, so a jump stands out at a glance.
• Slower pages flagged: a page is marked when its latest Load is at least 30% and 200 ms above its own median for the period, like the Load +65% in the example below.
• Site-wide trend: median TTFB, FCP, Load and weight across all pages by day, to tell one slow page from a slow site.
• Indexing and health: pages not in Google, errors, redirects, noindex and canonical to another URL, each with its day.
• Up to 1,000 pages per project, added in bulk; re-check all or selected pages on demand; CSV export.

Each page check costs 1 credit, and the free plan includes 450 credits a month, no card required. Email alerts when a page drops out of Google, starts returning an error or gets slower are coming soon. More on the project type in the features overview.

Start monitoring free