Get an Updated Page Recrawled: URL Inspection & Sitemaps

After you update a page, Google does not see the change until it recrawls the page, and you cannot force that. What you can do is remove obstacles and send two kinds of signals: a per-URL indexing request in Search Console's URL Inspection tool, and an accurate sitemap with a truthful lastmod value. Both are hints, and neither guarantees a timeline. Blog editors, SEO leads and agency content managers will find below a routine for each situation and a way to describe the wait without overpromising.

A page that has never been indexed is a troubleshooting problem and sits outside this topic. The focus here is a page that already exists in Google and has just been changed.

The gap between publishing and indexing

Two copies of your page

At any moment after an update there are two versions of the page: the one on your server and the one Google last stored. Google's URL Inspection help page (Opens in a new tab) states that the results it shows come from the latest indexed version of a page, not the live version on the web. It also describes a live test in which the tool fetches and examines the URL in real time. Understanding which version you are looking at prevents one misdiagnosis in particular: seeing the old text in the index and concluding that the update failed.

Three conditions must hold in order. The page must be current on your site. Google must recrawl it and see the new version. Only then can the new version be reflected in the index. You control the first condition completely; the tools below help with the other two without promising speed.

Example scenario: a software pricing page

Example scenario: A software company changes the feature list on its pricing page after a product release. A day later, the search result still shows the old feature list. The marketing lead wants the page "resubmitted" at once. The SEO lead first opens the page in URL Inspection and reads the indexed version: it is the old copy, as expected. The live test returns the new page without errors. The crawled page view shows the new feature list inside the HTML Google receives. With those three facts in hand, the SEO lead sends an indexing request, confirms that the sitemap entry for the page carries a fresh lastmod, and writes the date in the log. The marketing lead hears an accurate message: the page is correct, Google has been notified and the documentation gives a range, not a date.

Pre-flight table

Deciding what counts as substantial is a content audit question. The guide on running a content audit explains how to identify the pages that deserve maintenance, which is the right input to this routine.

One page: the URL Inspection routine

Step one is the live test

The URL Inspection help page describes the "Test live URL" action as a way to run a live test of a URL in your property to check for indexing issues, structured data and more. Run it before anything else, because if something blocks Google from seeing the new version, an indexing request is wasted. The tool has a boundary: the URL must belong to the property you are working in. For a URL in a property you do not own, the help page points to other tests such as the Rich Results test. Agencies should therefore secure access to client properties at the start of an engagement.

Reading the crawled page

According to the help page, "View crawled page" shows the raw HTML returned, the HTTP headers, the JavaScript console output and the page resources loaded. That is the evidence you need to confirm that Google receives the new text. If the new text appears only after a script runs in the browser, check whether it is present in the HTML Google received. The page adds that extra response information is available only for URLs that are on Google or on Google with issues.

Practical suggestion: after an update, look at three things in the live test and the crawled page. Is the new title and main content present in the HTML? Is the response code what you expect? Do the critical resources load? If all three are fine, the indexing request is the logical next step.

The indexing request and its limits

The help page says you can request that an inspected URL be indexed and that submitting a request does not guarantee the page will appear in the Google index. It also states that there is a daily limit on the number of indexing requests you can submit, and that inspections and live inspections have their own per-property daily limits. The limits can change, so read the current help page before relying on any figure; none is quoted here.

Nothing in the documentation says that sending the same request again speeds anything up. Repeating it can only consume quota. After sending a request, use the same tool to check progress, as the page itself suggests.

The seven-step routine

1. Confirm the new version in your browser.
2. Paste the URL into the inspection bar in Search Console.
3. Read the indexed version and its last crawl information. An old indexed copy means the recrawl has not happened yet.
4. Run "Test live URL". If something is wrong, fix it first.
5. If the live test is clean, choose "Request indexing".
6. Record the request date in your log and do not repeat the request before the documented range has passed.
7. Check the indexed version again after the range described in the help page.

Many pages: sitemaps that tell the truth

When Google uses lastmod

The sitemap documentation says Google uses the lastmod value if it is consistently and verifiably accurate, for example when it matches the page's last modification, and that the value should reflect the date and time of the last significant update. Read in practice, that means a sitemap that stamps every page with today's date teaches Google to ignore the field. Change lastmod for a page only when its content changed in a way a reader would notice. The full rules are on Google's sitemap building page (Opens in a new tab).

The same page says Google ignores the priority and changefreq values. Effort spent tuning them is wasted; effort spent on lastmod accuracy is not.

Ways to hand over a sitemap

The documentation lists submitting the sitemap in the Search Console Sitemaps report, using the Search Console API, or adding a line to robots.txt, in which case Google finds it the next time it crawls that file. For Atom or RSS feeds, WebSub can broadcast changes to search engines. The page also stresses that submitting a sitemap is merely a hint and does not guarantee that Google will download it. It says nothing about older ping addresses, so none are recommended here.

Size limits and splitting

A single sitemap file is limited to 50 MB uncompressed or 50,000 URLs, according to the documentation. A larger site has to split its sitemap into several files. Google's limits can change, so check the current page before you plan around them. The rule for lastmod stays the same across files: only a real update moves the date.

Verifying what your generator writes

Practical suggestion: find out what triggers lastmod in your publishing system. It might change whenever a page is saved, or only when content fields change. If a comment, a template tweak or a media library refresh moves the date on every page, the value no longer meets the "verifiably accurate" standard. Pick a few sitemap entries at random and compare their dates with the real last change of each page. If they disagree, tie the field to substantial content edits only.

Choosing between the two routes

For one important page, URL Inspection is the right tool. For many pages updated in the same period, or a structural change across the site, keeping the sitemap accurate scales better because the daily request limit cannot cover hundreds of URLs. In practice the two routes complement each other: the sitemap stays truthful all the time, and URL Inspection adds a targeted step for the pages of highest value.

Reading the timeline honestly

What the documentation says about time

The URL Inspection help page says indexing typically takes only a day or so but can take much longer in some cases, and that it can take up to a week or two. These are descriptions, not commitments. Telling a client "visible tomorrow" is a promise the source does not make; "the documentation describes a range from about a day to a couple of weeks" is accurate. The same page explains that "URL is on Google" means a page is eligible to appear in search results but is not guaranteed to be there, so being indexed is not the same as ranking. The wording in the documentation can change, so check the current page before quoting it.

What to avoid

• Sending several requests for the same URL in one day. The documentation shows no benefit and the quota is limited.
• Requesting indexing for every small edit. Save the limited quota for changes that matter.
• Faking lastmod values. Accuracy is the condition for the field being used.
• Deleting and republishing a page. The address, links and history can be lost.
• Editing the page again and again because the result has not changed. Each edit makes the wait harder to interpret.

Stakeholder wording

Decision rule

When the page still looks old

Likely explanations

If the indexed copy stays old after the documented range, check three things. The canonical may point to a different URL, so the page Google indexes is not the one you edited. A redirect may send requests elsewhere. Or the live test may reveal a blocker you missed. Duplicate pages can also produce this pattern: when two URLs serve the same intent, Google may be showing the other one. The guide to detecting keyword cannibalization helps you tell whether two of your pages are competing. A page that was never indexed is a different diagnosis and is not covered here.

Example scenario: a language school timetable

Example scenario: A language school updates its autumn timetable page. Weeks later the index still shows the old timetable. The team inspects the URL and finds that the canonical points to an older page that carries last year's timetable. The update was fine; the problem was the canonical tag. After correcting the canonical so that it points to the updated page, and ensuring the redirect and sitemap agree, the team sends a new indexing request and logs it. The lesson is that an old indexed copy sometimes points to a signal conflict, not to a slow crawl.

Moves and URL changes

If an update also changes the address, it is a move and not a content update. A permanent redirect from the old URL to the new one is needed, the sitemap should list only the new address, and internal links should be updated. After the move you can run the live test on the new address and send an indexing request there when appropriate.

Checklist for the day of the update

Before you publish

The recrawl process starts before the update goes live. Write one sentence describing the change; it will feed the log and, if needed, the client report. Keep a copy of the previous version. While the index still holds the old page, a reader may report "the result said something different", and the copy lets you compare what was live at each moment.

• Confirm the change is substantial: new information, a corrected step or an updated table.
• Check that the title, description and headings agree with the updated content.
• Check that the canonical points to the page itself.
• Check inbound and outbound internal links.
• If the page uses structured data, run the live test and confirm it reports no errors; the help page says the tool can check structured data as well.
• Update the page's lastmod in the sitemap.

After you publish

Run the live test first. If the change is substantial and the test is clean, send the indexing request. After that, the useful action is waiting with a plan: fill in the log, move on to the next page and put the check date on the calendar.

Why the old snippet may linger

The documentation says nothing specific about how long a title or description in a search result takes to change, so no timing is given here. Practical suggestion: if the indexed version is still old, treat an old snippet as expected, and use URL Inspection to confirm whether what the result shows matches the indexed copy.

Example scenario: a local newspaper correction

Example scenario: A local news site corrects a factual error in an article. The editor wants the correction visible in search quickly because readers may rely on it. The team runs the live test, confirms that the corrected paragraph is in the crawled HTML, sends one indexing request and notes the date. They also leave a visible correction note on the page itself, so a reader who arrives from an older snippet still sees the right information immediately. The lesson is that the page on your own site is the first place a reader meets the correction, and the recrawl handles the rest on Google's schedule.

Common misreadings

A log that keeps the team honest

Columns

Managing requests from memory is error-prone. A simple log shows what was done on which page and when, and prevents wasted quota.

Roles

Three people touch the process. The content owner decides that the change is substantial and writes the summary. The SEO lead runs the live test, sends the request and verifies the sitemap date. The editor closes rows at the monthly review. Separating the roles makes it clear who sent a request and avoids two people requesting the same URL.

Pairing the log with refresh work

The decision to update a page comes from your refresh process; the guide to refreshing old blog posts covers it. The log records only what happens after the update. Keeping the two records apart preserves the difference between "we updated and Google has not seen it yet" and "the update was not needed".

Measuring after the update

A recrawled and indexed update does not by itself imply a traffic recovery. The documentation does not link recrawling to ranking improvement. If you want to watch performance after a refresh, compare equal periods before and after and keep other changes to a minimum, as the guide to finding articles that lose traffic suggests. The log's purpose is to track recrawling and the indexed version, not to promise traffic.

Priorities in bulk updates

When hundreds of pages change at once, the daily limit means you cannot request all of them. Rank pages by business value: pages that matter commercially, that attract visitors and whose information changed substantially go first. For the rest, an accurate sitemap is enough. Add a priority column to the log and keep column names stable over time.

Agency reporting

For agencies, expectation management is half the job. A client report should list "request sent" and "indexed version updated" as separate lines, because the first is within your control and the second depends on Google's schedule. Add the documented range and the note that nothing is guaranteed, and later disagreements become much less likely.

Frequently Asked Questions

How long does it take for an updated page to be recrawled?

Google's URL Inspection help page says indexing typically takes only a day or so but can take much longer in some cases, and up to a week or two. There is no date commitment. The figures in the documentation may change, so check the current page.

Does requesting indexing several times help?

The documentation shows no benefit from repeating a request for the same URL. The help page says a request does not guarantee that the page will appear in the Google index and that there is a daily limit. Repeating requests only uses quota.

Is submitting a sitemap enough?

Google's sitemap documentation calls submission merely a hint and says it does not guarantee that Google will download the sitemap. For many updated pages, an accurate sitemap helps; for one important page, URL Inspection adds a targeted step.

Should lastmod always show today's date?

No. Google says it uses lastmod if it is consistently and verifiably accurate, and the value should reflect the last significant update. Stamping every page with the same date weakens the signal.

Can I inspect a URL on a site I do not own?

The help page says the inspected URL must be in the current property. For a property you do not own, other tests such as the Rich Results test apply. Agencies should secure client property access first.

Will a recrawl improve my ranking?

The documentation draws no link between recrawling and ranking. A page that is indexed is eligible to appear in results, but Google does not guarantee that it will appear or rank higher.

Conclusion

To get an updated page recrawled, test the live URL in URL Inspection, send an indexing request when the test is clean, keep the sitemap's lastmod truthful, and track the process in a log. Google's documentation describes a range from about a day to a couple of weeks, says an indexing request does not guarantee the page will appear in the index and calls a sitemap submission a hint. Plan around those limits, not around a promised date.

If you want help producing or refreshing the content that deserves a recrawl, see our content writing service.