How to Get Google to Reindex Your Site After Changes

Google reindexes a page when it crawls it again and processes the new version. You cannot force that crawl, but you can make it happen sooner: request indexing for the pages that matter most, set an accurate lastmod on every changed URL in the sitemap, link the changed pages from pages Google visits often, and clear out old URLs so the crawl is not wasted on them. For a handful of pages this takes hours to days. For a whole site after a redesign or migration, expect weeks.

Recrawl and reindex are two steps

"Reindex" bundles two things Google does separately. First Googlebot fetches the URL again (the recrawl). Then Google processes what it fetched, renders it, compares it with what it had, and updates the index entry (the reindex). The second step can lag the first by hours or days, which is why a page can show a fresh Last crawl date in URL Inspection while search results still show the old title.

Everything below is about triggering the first step. The second follows on its own, provided the new version is indexable.

Match the method to the change

Situation	Best route	Also do
A few updated pages	Request indexing per URL	Update their lastmod
Many updated pages (new template, bulk edit)	Accurate lastmod in the sitemap	Link them from the home page or hub pages
Fixed a block (noindex, robots.txt, 5xx, 403)	Validate fix in the Page indexing report	Request indexing for the top pages
Moved pages or changed the domain	301 redirects, Change of address tool for domain moves	Keep the old sitemap live for a while
Deleted pages	Return 404 or 410, remove from sitemap	Removals tool only if it is urgent
Job postings or livestreams	Indexing API, URL_UPDATED	Keep structured data valid

Route 1: request indexing for the pages that matter

For a small number of URLs this is the fastest signal you can send.

1. Open URL Inspection in Search Console and paste the URL.
2. Click Test live URL. This fetches the page now and shows what Google would get: status code, rendered HTML, screenshot. If the live test shows the old content (a cache in front of the server, for example), fix that first; requesting indexing of a stale page is pointless.
3. Click Request indexing.

Google queues the URL for crawling. It does not publish the daily allowance; in practice a property gets around ten requests a day before the button reports that the quota is exceeded. Google also says that submitting the same URL repeatedly does not get it crawled faster. One request per real change is the rule. The limits and what to do when you have more pages than requests are in request indexing limits.

Route 2: tell Google what changed through lastmod

Google reads your submitted sitemaps on its own schedule and uses <lastmod> to decide which known URLs deserve another fetch, as long as the values have been reliable. That makes lastmod the right mechanism for bulk changes: update it on the URLs you changed, and only those.

<url>
  <loc>https://www.example.com/pricing</loc>
  <lastmod>2026-10-11T09:30:00+00:00</lastmod>
</url>

Three rules:

• Set lastmod to the time the content meaningfully changed, not the build time, not the time a comment was posted.
• Never stamp every URL with today's date. Google says it uses lastmod when it is consistently accurate; one mass update makes it stop trusting the field for your site.
• If you use a sitemap index, update the index entry's lastmod too, so Google knows which child file to re-read.

Resubmitting the sitemap itself is optional. It records a new submission date and nothing else; the old ping endpoint has been switched off since the end of 2023. Lastmod best practices covers the edge cases.

Route 3: validate the fix for pages that were blocked

If pages were missing because of a technical reason (noindex, robots.txt, a server error, a 403 from the firewall), open Indexing > Pages, click the reason, and press Validate fix after you have corrected it. Google rechecks a sample first and then the rest of the group. Google's documentation says validation typically takes up to about two weeks, and it can take longer. In the meantime, request indexing for the few URLs that bring the most traffic so they come back first.

Route 4: link the changed pages from pages Google crawls often

Googlebot recrawls the home page, main category pages and fresh content far more often than deep pages. A link from one of those to a changed page is a direct invitation. Practical versions of this:

• A "recently updated" block on the home page or in a hub page.
• A link from the newest blog post to the page you updated.
• Fixing internal links that still point at old URLs after a migration, so the crawler is not spending its visits on redirects.

Pages with no internal links wait the longest. Search Console's Links > Internal links report lists them at the bottom, with zero or one link.

Route 5: the Indexing API, for the pages it is meant for

The Indexing API lets you push a URL to Google with a URL_UPDATED notification, which usually results in a crawl within hours. Officially it is only for pages with JobPosting or BroadcastEvent structured data, Google's documentation says so, and the quota is 200 publish requests per day per Google Cloud project. Google also names spreading one site across several projects to get more quota as abuse that can lead to revoked access. If you run a job board or livestream pages, use it. If you run a shop or a blog, it is not the route Google wants you to take.

Migrations: let the redirects carry the signal

After a domain move or a URL structure change, Google reindexes by crawling the old URLs, following the 301 redirects and indexing the new ones. You help it by:

1. Redirecting every old URL to its exact new equivalent, one hop, not to the home page. The redirect checker shows the full chain for a URL, so you can catch the old-to-old-to-new hops.
2. Keeping the old sitemap submitted for a while, so Google keeps crawling the old URLs and discovering the redirects. Add the new sitemap alongside it.
3. Using Settings > Change of address in Search Console for a domain change.
4. Updating internal links, canonical tags and hreflang to the new URLs.

The old URLs show up as "Page with redirect" in the Page indexing report, which is correct and expected. Removing them from Google's memory is not the goal; moving the signals is. The whole sequence is in the site migration indexing checklist.

Clear out what should not be reindexed

Recrawl capacity spent on dead URLs is capacity not spent on your updated pages.

• Pages that no longer exist should return 404 or 410, not a 200 "not found" page (a soft 404) and not a redirect to the home page.
• Remove deleted and redirected URLs from the sitemap.
• If a removed page must disappear from results quickly (a leaked document, an old price list), use Indexing > Removals for a temporary removal of about six months while the 404 does the permanent job.

What to expect

• A requested URL: often recrawled within a day, sometimes within an hour, sometimes several days.
• URLs with updated lastmod: days to a couple of weeks, depending on how often Google already visited them.
• Deep pages nobody links to: weeks to months.
• Search results: updated some time after the crawl, not at the moment of the crawl.

Track progress with the Last crawl date in URL Inspection for individual pages, and with the Page indexing report for the whole site. For a quick pass over a list of changed URLs, the Google index checker reports whether each one is currently indexed. A page whose last crawl date is older than your change has not been seen yet; a page crawled after your change but still showing old content is waiting for processing. When did Google last crawl my page covers every place that date lives.

What not to do

• Request indexing for the same unchanged page every day. It does not raise priority and it uses up the allowance you need for real changes.
• Remove and re-add the sitemap to simulate a resubmission. It restarts the sitemap status and changes nothing about crawling.
• Set every lastmod to today on each deploy. Google learns to ignore the field.
• Make cosmetic edits (a new date, a reworded sentence) to make a page look changed. Google compares content, and an unchanged page is reprocessed to the same result.
• Block old URLs in robots.txt after a migration. Google then cannot see the redirects and the old URLs stay in the index with no content.
• Open several Google Cloud projects to get more Indexing API quota for one site. Google treats it as abuse.

Keeping the loop running without the manual work

The manual loop is: change a page, update lastmod, request indexing for the important ones, check Last crawl a few days later. TurboIndex runs that loop from your sitemaps: when a URL's lastmod changes it is queued again, fetched once by TurboIndexBot to confirm it still returns 200 without a noindex or a redirect, submitted, and then checked through the URL Inspection API after 2, 3, 5, 7 and 14 days so you can see whether the new version made it in.

What to do next

1. List the URLs that changed and sort them by traffic.
2. Request indexing for the top ten after a live test of each.
3. Update lastmod on all changed URLs and on the sitemap index.
4. Add internal links from the home page or hubs to the changed pages.
5. Check Last crawl on a sample after three days, and the Page indexing report after two weeks.