How long does Google take to index a change? It depends on what you changed, and since 2 October 2026 there are numbers from Google for each case: 1 to 2 days for a new title to show, 1 to 3 weeks for a canonical change and 1 to 3 months for a domain migration.
That day, at the Search Central Live Deep Dive in Barcelona, Gary Illyes showed the internal timings Google works with to crawl, index and show a page. Three more typical figures sit alongside those: about 20 hours to discover a new URL, about 30 days to come back to one it already knows, and 3 to 6 months to recover from a core update. One warning is worth having from the start: Google has not defined what “typical” means.
That is why things like this happen: you change a canonical and ten days later nothing has moved, or you migrate a domain and three weeks in traffic looks odd. These figures tell you whether that is normal.
Where do these figures come from, and how far can you trust them?
The chain of sources is this. Gary Illyes, from Google, presented the timings at the Search Central Live Deep Dive in Barcelona. John Campbell, of ROAST, captured them in his day 3 recap of the event. They have since been covered by Search Engine Roundtable, in a piece by Barry Schwartz dated 5 October, and by Search Engine Journal, in one by Matt G. Southern dated 4 October. The tables in this article follow Campbell’s recap. As of Search Engine Journal’s publication, the slides were not on Google’s events page. We checked every source in this article on 7 October 2026.
Three caveats change how to read them:
- “Typical” is not defined. Neither the sample nor the period of measurement is known.
- They are Google-wide figures. We do not know whether they change with the size of a site, or by how much.
- Illyes presented them as an exercise. He later told Schwartz he wanted to see whether the audience could relate to the internal numbers they had pulled.
According to the recap, each process had a fastest, a typical and a slowest time, but the tables only include the last two. So everything that follows is a reference, not a deadline.
Crawl, index, serve: why delays add up
When you publish or change a page, Google does three things in order. First it crawls it: Googlebot finds the URL and downloads it. Then it indexes it: it processes the page and decides whether to store it in its index. Finally it can show it in the results. Illyes pointed out that many of these processes are linked, and the practical consequence is that a delay in one stage carries into the next: a page is not indexed until it has been crawled, and it is not shown until it has been indexed.
Crawl
Googlebot finds the URL and downloads it.
Index
Google processes it and decides whether to store it in the index.
Serve
The page can appear in the results.
That is why a single figure misleads. End-to-end indexing taking about an hour and a half does not mean your page shows up in an hour and a half, because Google has to have reached it first. To get a sense of the whole journey you have to look at the three tables and add them up.
These are the ten timings most often used, with the typical and the slowest:
Discover a new URL
Typical~20 hours
SlowestWeeks or never
Recrawl a known URL
Typical~30 days
SlowestWeeks or never
Process a sitemap
Typical~24 hours
SlowestUp to 14 days or never
robots.txt change
Typical~24 hours
Slowest25 hours
Index end to end
Typical~1.5 hours
SlowestMonths or never
Canonical change
Typical1-3 weeks
SlowestMonths
New title or snippet
Typical1-2 days
SlowestWeeks or months
Manual action removal
Typical1-2 weeks
Slowest4-6 weeks
Domain migration
Typical1-3 months
Slowest6 months to 1 year+
Core update recovery
Typical3-6 months
Slowest6 months to 1 year
The rest of this article goes through the three stages with the full table for each.
How long does Google take to crawl a page?
Short answer: about 20 hours to discover a new URL and about 30 days to come back to one it already knows. The six crawl rows, with the typical and the slowest:
| Process | Typical | Slowest |
|---|---|---|
| Discovery (new URL) | ~20 hours | Weeks or never |
| Refresh (known URL) | ~30 days | Weeks or never |
| Sitemap processing | ~24 hours | Up to 14 days, or never (quality) |
| robots.txt update | ~24 hours | 25 hours |
| Crawl capacity update | 4 hours to 1-2 weeks | 1-3 weeks (in recovery) |
| Crawl demand update | ~20 hours | Weeks to months |
Discovering a new URL: about 20 hours
This is how long Google typically takes to find out a page exists. Normally it is a little over a day. At the slow end the recap says “weeks or never”, and the important nuance is that “never” is usually tied to quality: if Google sees no reason to crawl the URL, a technical fix does not change that.
Recrawling a known URL: about 30 days
This is the figure that stands out. If you change something on a page that already exists, Google typically takes around a month to come back to it. Until then, as far as Google is concerned, the page is still the old one.
Google says something similar, with a different range, when you ask for a specific crawl. In its documentation on asking Google to recrawl your URLs it says “Crawling can take anywhere from a few days to a few weeks”, and it warns that requesting a crawl does not guarantee the page will reach the results. The two figures measure different situations, normal crawling and requested crawling, and there is no reason to expect them to match.
Processing a sitemap: about 24 hours
When a new URL enters a sitemap, Google typically processes it within a day. At the slow end it is up to 14 days or never, again with quality as the reason. A sitemap helps Google discover URLs, but it does not force Google to crawl or index them. If you need to pull the URLs out of a sitemap to review them, we explain how to extract URLs from a sitemap.
robots.txt: about 24 hours, and 25 at most
This is the most predictable row in the table: from typical to slowest there is one hour of difference. If you change robots.txt, count on a day. It is worth knowing before a delicate change, because during that time Google may keep applying the previous version.
Crawl capacity and crawl demand: two different dials
The recap separates crawl capacity from demand. According to Google’s documentation, capacity limits the total time your server spends holding connections open for Google: it depends on how many parallel connections there are and how long each one lasts. It goes up when responses are stable and fast, and down with slow responses, 5xx errors or limit signals such as the 429 status code. Demand, on the other hand, depends on factors such as the size of the site, how often it changes, and the quality and relevance of its pages compared with other sites.
The timings: capacity takes 4 hours to 1-2 weeks to update, and up to 1-3 weeks if it is recovering. According to the recap, it can drop within seconds if the server has problems. Demand is about 20 hours typically and weeks to months at the slowest.
One precision about that Google guide: it is aimed at very large sites (around a million pages with weekly changes, or more than ten thousand with daily changes) and at sites with many URLs in “Discovered - currently not indexed”. If your site is smaller, you do not need to go into that detail.
How long does Google take to index a page?
Short answer: the end-to-end indexing process takes around 1.5 hours typically, but some processes take weeks or months or never finish, and a canonical change (1-3 weeks) or a migration (1-3 months) go much slower. The ten indexing rows:
| Process | Typical | Slowest |
|---|---|---|
| Rendering | Seconds to render, hours in queue | Days to weeks |
| Meta annotations | 45-90 minutes | 1-4 days |
| Link annotations | Minutes to 1-3 weeks | Months |
| Indexing (end to end) | ~1.5 hours | Months or never (quality) |
| Removal | 1-3 weeks | Months |
| Canonicalization change | 1-3 weeks | Months (conflicting signals) |
| Site move | 1-3 months | 6 months to 1 year+ |
| Structured data updates | Hours to 1-2 weeks | Weeks or never (quality) |
| Images | Hours to days | Weeks to months |
| Videos | Hours to days | Weeks to months (deep analysis) |
The recap does not detail what each row includes. The explanations below are our reading of each name, and we flag it where there is doubt.
Rendering: seconds to render, hours in the queue
Rendering is running the page to see the content as a browser would. The process itself takes seconds, but the page waits in a queue, and that wait is hours typically and days to weeks at the slowest. If your important content only appears after JavaScript runs, that queue adds to the crawl time.
Meta and link annotations
From the names, our reading is that meta annotations refer to the page’s meta tags, such as the one saying not to index, and link annotations to link attributes, such as the one saying not to follow a link. If so, changes to meta tags show in 45-90 minutes typically (and up to 4 days at the slowest), while link changes go from minutes to 1-3 weeks, with months at the slow end. This is our reading: Google has not said what each row includes.
End-to-end indexing: about 1.5 hours
The recap defines “end to end” as the point where all the critical processes finish successfully. It is a figure that lends itself to misunderstanding, and we do not know whether it counts from the moment of the crawl. Read on its own it seems to say a page is indexed in an hour and a half, which does not fit the 20 hours of discovery or the 30 days of refresh in the earlier rows. The prudent reading is the time of the indexing process once Google has already reached the page. At the slow end it is months or never, again with quality as the cause.
Removal: 1 to 3 weeks
This is how long a URL takes to leave the index when it is removed or blocked, with months at the slowest. It should not be confused with removal from Search Console, which is in the serving table and is much faster.
Canonicalization change: 1 to 3 weeks
If you change which URL you declare canonical, expect one to three weeks typically, and months if the signals contradict each other: for example, a canonical that says one thing while a sitemap or internal links say another. That is why a canonical changed five days ago tells you nothing yet.
Site move: 1 to 3 months
Typically between one and three months, and from six months to over a year at the slowest. The recap adds a nuance: a small move can be done in a few weeks. Google’s documentation agrees: on a small or medium-sized site, most pages are reflected within a few weeks, and larger sites take longer depending on the number of URLs and the speed of the server. With those ranges in front of you, planning an SEO migration means warning management that there will be turbulence for months. We cover what usually goes wrong in SEO migrations: 10 critical errors.
Structured data, images and videos
Structured data takes hours to 1-2 weeks, and weeks or never at the slowest, with quality as the cause. Images and videos take hours to days typically and weeks to months at the slowest; for videos, the recap points to deep analysis as the reason.
How long until a change shows up in Google’s results?
Short answer: a new title or snippet shows 1 to 2 days later, and recovering from a core update can take 3 to 6 months. The seven serving rows:
| Process | Typical | Slowest |
|---|---|---|
| Removal in Search Console | ~2 hours | 24 hours |
| Snippet update | 1-2 days | Several weeks or months |
| Title update | 1-2 days | Several weeks or months |
| Text result image update | 1-2 weeks | Several weeks or months |
| Manual action removal | 1-2 weeks | 4-6 weeks (or longer for dormant sites) |
| Core update change | 3-6 months to recover | 6 months to 1 year (next update) |
| Spam update change | 1-2 weeks (continuous) | Months (batch refreshes) |
Removing a URL from Search Console: about 2 hours
This is the fastest row in the whole list, which is why it works for emergencies, such as a page that should not be visible. If you own the property, typically it takes two hours and, at the slowest, 24.
Title and snippet: 1 to 2 days
A new title or description usually shows within one or two days, but the slow end reaches several weeks or months. If you change a title and three days later you do not see it, you are still within normal.
Image in the text result: 1 to 2 weeks
A change to the image that accompanies a text result takes one to two weeks typically, and several weeks or months at the slowest.
Manual action: 1 to 2 weeks
Removing a manual action takes one to two weeks typically, and 4 to 6 weeks at the slowest, or much longer for dormant sites.
Core update: 3 to 6 months to recover
This is the most uncomfortable figure. If a core update has hurt you, typically you wait three to six months to recover, and six months to a year if you have to wait for the next update. The recap adds that a core update takes 2 to 4 weeks to roll out.
Google’s documentation confirms the essentials: it recommends waiting at least a full week after the update completes before analyzing your site in Search Console, says some changes can take effect in a few days but broader improvements can take several months for its systems to learn and confirm, and that if you see no effect after a few months, “that could mean waiting until the next core update”. We looked at the previous case in a Google core update with new anti-spam policies.
Spam update: 1 to 2 weeks
Changes from a spam update show in 1 to 2 weeks typically, and at the slowest they take months if they are applied in batches. According to the recap, the rollout is much faster than a core update’s: 1 to 2 days.
Six rules for using these figures
1. Write down the date of the change before calling it a failure
A canonical changed five days ago tells you nothing yet, because typically it is one to three weeks. A simple way to work is to note the date of each change and, before calling anything a failure, compare it with the matching row in the tables.
2. If it is urgent and the URL already exists, request indexing
In Search Console, the URL Inspection tool has a “Request indexing” button. Google recommends it for a few URLs, and warns of three things: it guarantees nothing, there is a quota for submitting individual URLs, and requesting the same URL several times will not get it crawled any faster. As a complement, and this is our recommendation, link the URL from a page Google visits often, such as the home page.
3. Change the sitemap lastmod only when the content changes
Google uses the lastmod value only when it is “consistently and verifiably” accurate, and says it should reflect the last significant update to the page: changes to the main content, structured data or links. Changing the copyright year does not count. If your sitemap updates the date on every page every day, Google has reason to stop trusting it.
4. Tell “Discovered” from “Crawled” in the indexing report
They are different statuses with different causes. According to Google, in “Discovered - currently not indexed” the page “was found by Google, but not crawled yet”, and it is usually because Google postponed the crawl so as not to overload the site. It is worth checking that the server can handle crawling and that the page is linked or in a sitemap. In “Crawled - currently not indexed”, Google has already visited and has not indexed it: that is where you look at the quality and uniqueness of the page, and whether it is a duplicate or has a canonical or a noindex that explains it. When a URL has been in either state for weeks, you are no longer waiting: you are in the “never” column, and time will not fix it. If it still does not move after you have checked all that, it is work for technical SEO.
5. In a migration, warn of 1 to 3 months of turbulence and keep the redirects
Management needs to know from the start that a migration does not settle in a week. And redirects are not removed early: Google recommends keeping them “for as long as possible, generally at least 1 year”.
6. After a core update, do not rebuild the site two weeks later
Typically it is 3 to 6 months, and Google recommends waiting at least a week after it finishes before analyzing anything. Rebuilding a site two weeks in, without knowing what changed, is the most expensive way to be wrong.
What we still do not know
- Sample, period and what “typical” means. Illyes later clarified it was an exercise to see whether the audience related to the figures. There is no published methodology.
- Whether it changes with the size of the site. The figures are Google-wide, not yours. A hundred-page site and a million-page site do not have to share the same timings.
- The fastest times. The recap says every process had one, but the tables do not include them.
Our reading: many alarms arrive before Google’s clock has had time to do anything. These figures are not for sitting still, but for knowing when to wait and when to start looking for the fault. If you have been waiting weeks on a change and do not know which side you are on, tell us about your project and we will take a look.
Frequently asked questions
How long does Google take to index a new page?
According to the timings Gary Illyes showed, typically about 20 hours to discover a new URL and about 1.5 hours for the end-to-end indexing process. At the slowest, discovery can take weeks or not happen, and indexing can take months or not happen, usually because of quality. Adding the stages together, real time can be well above each figure on its own.
How long does Google take to recrawl a page it already knows?
Typically about 30 days, and at the slowest, weeks or never. If you change something on an existing page, Google can take around a month to come back to it. If it is urgent, you can request indexing of the URL in Search Console, though Google warns it is not guaranteed.
How long does a new title or snippet take to show?
1 to 2 days typically, and several weeks or months at the slowest. If you changed a title three days ago and cannot see it, you are still within normal.
How long does a site take to recover from a core update?
Typically 3 to 6 months, and 6 months to a year if you have to wait for the next update. Google recommends waiting at least a full week after the update completes before analyzing your site, and warns that broader improvements can take several months to be confirmed.
How long do the results of a domain migration take to show?
1 to 3 months typically, and 6 months to over a year at the slowest. A small move can be done in a few weeks. Google recommends keeping redirects, generally, for at least a year.