How to index a website on Google and confirm it actually worked

Requesting indexing in Search Console doesn't prove Google came back to the page. The real signals are the last crawl date, the referring page, and the sitemap's last read.

If you've ever requested indexing for a page in Search Console, you know the feeling: you click the button, get the «indexing requested» message, and then… nothing. The question that's left unanswered is whether Google actually went back to the page, or whether the request stayed just that — a request.

The answer isn't in the button you clicked. It's in three different places in Search Console that rarely get looked at together: the last crawl date, the referring page field, and the sitemap's last read date. Each one tells you something different, and it's easy to draw the wrong conclusion from looking at just one of them.

The last crawl date isn't what it looks like

When you open URL Inspection, the first number that jumps out is the last crawl date. It's tempting to treat it as proof that «everything's fine» — but that date freezes at Google's first visit, and only changes if it comes back.

If you requested indexing yesterday and the date still shows the day you originally published the page weeks ago, that's information. It doesn't prove something is wrong — it could just be a matter of crawl priority — but it doesn't confirm the request had an effect either.

There's a distinction here that Google's own URL Inspection documentation explains, but that gets missed: the live test (the button you use to request indexing) checks whether the page is accessible right now, not whether Google actually recrawled it for indexing purposes. Those are different things, and treating them as the same one is where a lot of frustration comes from.

This also isn't the same problem as pages marked as crawled but currently not indexed — there, Google already visited the page and decided not to index it. Here the issue comes earlier: it never came back at all.

«No referring page detected» doesn't mean total isolation

This is the field that triggers the most alarm, and with some reason — but it's also the most misread. It refers to the page Google says it used to discover your URL. When it's empty, it's tempting to conclude the page is completely cut off from the rest of the site.

It's not quite that simple. Search Console doesn't always report this field even when real internal links exist — it's not a complete inventory of everything pointing at that URL, just whatever Google decided to show.

That said, if the field is empty and the crawl has been stuck for weeks, it's worth actually checking: open the related pages that are already indexed and confirm there's a real, clickable link to the new page. A clinic page about a specific treatment should have a natural link from the matching specialty page; a real estate listing for a neighborhood should link back to the area guide it belongs to.

The rule here is simple: link from related content, with an anchor that describes the destination — don't just bolt every link onto the footer to «have internal linking.» Readers need to understand why that link is there. And even if you do this well, it's not a guarantee of indexing or of a higher crawl frequency — it just helps discovery, nothing more.

A sitemap showing «Success» can still be weeks out of date

This is probably the most common mix-up. The Sitemaps report in Search Console shows two dates that look like the same thing and aren't: when you submitted the sitemap, and when Google actually last fetched it.

A sitemap can sit at «Success» — processed with no errors — and still not have been read in three weeks. If you added new pages after that last read, the report has no way of knowing they exist, because Google hasn't looked at the file again yet. Google's documentation on the Sitemaps report confirms this distinction, but it rarely gets read all the way through.

It's also worth confirming the sitemap points to the final address — not a variant that redirects or to a different canonical page. That just adds noise to signals you're already trying to interpret.

The six pages that sat still for almost seven weeks

This happened to us: six new pages — three AI Act Article 50 topics (chatbots for clinics, for agencies serving clients, and for real estate, each in Portuguese and English) — published the same day, with the last crawl date stuck on that same date nearly seven weeks later. All six showed «no referring page detected.»

We did two things: requested manual indexing for each of the six, and strengthened internal linking from already-published articles. That's what we applied — it isn't, by itself, proof that it worked. The next reinspection is what will actually tell us whether the crawl moved forward, and that distinction between «we applied the fix» and «we confirmed the result» is what separates a real diagnosis from wishful thinking.

If you want to reproduce this on your own site, the minimum worth tracking is: each page's publish date, the last crawl observed at each check, what shows in the referring page field, the sitemap's last read date, and the date you requested manual indexing. Without that log, it's easy to confuse coincidence with cause — especially when you're doing two things at once, like we were here. For anyone putting together Search Console reports for clients, this is exactly the distinction worth keeping straight.

The right order to investigate in

Don't start with content. Start with discovery mechanics, and only then move down to structure and quality.

First, confirm the sitemap: the final address is in there, it's accessible, and you know when it was last read. Also confirm nothing is blocking crawling or directly preventing indexing.

Next, request manual indexing — through URL Inspection, with the live test confirming the page is accessible before you submit the request. Log the date. Google's own guidance on recrawl requests is clear on one point: repeating the request doesn't speed anything up.

If the crawl is still stuck after that, that's when you go check internal linking — confirm it on the published page itself, not just in the CMS configuration, that the link actually exists.

Only at the end do you look at the content itself: near-duplicate pages, generic descriptions, text that doesn't answer what the searcher actually came for. A treatment page needs genuinely useful clinical information; a neighborhood page needs real local detail — padding the word count doesn't fix any of this.

A sitemap being read, a page being visited, and a page being indexed are three different things. To track this without losing the thread, DENVORA SEO's Search Console reporting is built around exactly this distinction — and requesting indexing is still just the first step, not the finished job.