How long does it take Google to notice website changes?

Short answer: typically 3 days to 3 weeks, and almost never the same day. Google has to re-crawl the changed page, re-index it, and re-rank it — in that order. Small edits on frequently-crawled sites can be picked up within days; the ranking movement you actually care about usually lands one to three weeks after the deploy. In the one change we measured end-to-end, rankings moved 16 days after the pull request merged.

You shipped the fix on Tuesday. You refreshed your rankings on Wednesday. Nothing moved. That doesn't mean the change didn't work — it almost certainly means you looked too early.

---

This is one of the most common ways engineering teams misread their own SEO. A change goes out, someone checks Search Console a day or two later, sees flat rankings, and quietly concludes the work didn't matter. Then weeks later the rankings move and nobody connects it back to the deploy, because by then twelve other things have shipped.

The lag between changing your code and Google acting on it is real, it's measurable, and it's longer than your release cadence. If you don't account for it, you will systematically misattribute your own results.

Here's the honest answer to how long it takes — and why.

Days to weeks, almost never hours

There is no single number, but there is a reliable shape. A meaningful on-page change typically takes somewhere between a few days and three weeks to show up as a ranking movement. Sub-24-hour ranking changes from a code deploy do happen, but they're the exception — usually on small, frequently-crawled sites making an unambiguous change.

The reason it isn't instant is that "Google noticing your change" is not one event. It's three, and they happen in sequence.

Three things have to happen first

1. Crawl. Googlebot has to fetch the changed page again. It doesn't watch your repo or your deploy pipeline — it comes back on its own schedule, which depends on how often your site changes and how much authority it has. A busy homepage might get crawled daily; a deep, rarely-updated page might wait weeks.

2. Index. Once fetched, the new version has to be processed and stored — the HTML rendered, the content extracted, the page re-understood. For JavaScript-heavy sites this stage adds its own delay, because rendering is queued separately from crawling. (If your site is a client-rendered SPA, this is where a lot of changes quietly stall — worth its own post.)

3. Re-rank. Only after the page is re-indexed does Google re-evaluate where it should rank, against the live competitive set for each query. This is the stage you actually care about, and it's the last one to move.

By the time a ranking actually moves, you may be two or three sprints past the commit that caused it. That gap is the entire reason attribution is hard.

What we actually saw

We don't have to argue this in the abstract. We ran our own product on one of our apps, ganttchart.ai, and watched a homepage change move its average ranking ~25 positions overnight.

The "overnight" part is the trap. The ranking moved overnight — but the pull request that caused it had merged 16 days earlier. For more than two weeks, anyone checking Search Console would have seen nothing and reasonably concluded the homepage update did nothing. Then on a single day, Google reindexed, decided the new copy was a sharper match for the queries it cared about, and re-ranked.

Sixteen days from merge to measurable movement, on a small, actively-crawled site, for a clear on-page content change. That's a good central estimate to carry around in your head — not a floor, not a ceiling, a center.

Why your lag will be different

The 16-day figure is one data point. Yours will vary with:

• Crawl frequency. High-authority, frequently-updated sites get re-crawled faster. A brand-new page on a small site can wait much longer to even be fetched.
• Change type. A title-tag or H1 change is cheap for Google to re-evaluate. A change that affects internal linking or site structure ripples across many pages and resolves more slowly.
• Rendering. If the changed content only appears after JavaScript runs, add time — rendering is a separate, slower queue.
• Query competitiveness. On a sleepy long-tail query, a re-indexed improvement can surface almost immediately. On a contested head term, Google is comparing you against everyone else and moves more cautiously.

What this means for measuring a deploy

The practical consequence: you cannot judge the SEO impact of a release by looking the next day. The signal isn't there yet. If you measure too early you'll record a false negative, and false negatives are how good SEO work gets deprioritized.

Two rules of thumb that follow directly:

• Give it at least two to three weeks before you call a change a failure. Earlier than that, flat rankings are uninformative.
• Your attribution window has to look backward, not forward. When a ranking does move, the cause is usually something you shipped one to three weeks prior — not yesterday's deploy and not today's. The natural human instinct (blame the most recent change) is almost always wrong here.

This is precisely the problem Code Results exists to solve: it runs changepoint detection on your Search Console history to find when a ranking actually moved, then looks back across the right window of merged PRs to find the one most likely responsible — instead of crediting whatever shipped most recently.

How to make Google notice faster

You can't remove the lag, but you can shorten the front of it:

• Keep an accurate XML sitemap with real lastmod dates so Google knows a URL changed.
• Use Search Console's URL Inspection → "Request indexing" for important single-page changes. It nudges the crawl queue; it doesn't guarantee a ranking move.
• Strengthen internal links to the changed page. Pages Google reaches more easily get crawled more often.
• Don't block rendering. If key content depends on client-side JavaScript, server-render or pre-render it so the index step doesn't stall.

None of this makes rankings move overnight. It makes the crawl and index stages faster, so the re-rank stage can start sooner.

Frequently asked questions

How long does it take Google to index changes to a page?

Crawling and indexing are the front half of the lag. A frequently-updated, well-linked page is usually re-crawled within a few days and re-indexed shortly after; a deep page on a small site can wait weeks to be fetched at all. You can check the last crawl date for any URL with Search Console's URL Inspection tool — if it predates your deploy, Google hasn't seen the change yet.

How long do SEO changes take to take effect?

Plan on one to three weeks between shipping a change and seeing ranking movement. Same-day movement happens, but it's the exception — usually a small, frequently-crawled site making an unambiguous change on an uncontested query.

How long does it take Google to re-rank a page after an update?

Re-ranking is the last stage: it can only start once the page has been re-crawled and re-indexed. In the deploy we measured end-to-end on ganttchart.ai, the gap from merged pull request to visible ranking movement was 16 days — and when the movement came, it landed in a single day.

Can you make Google notice website changes faster?

You can shorten the crawl and index stages: keep your sitemap's lastmod dates accurate, use Search Console's "Request indexing" for important pages, strengthen internal links to the changed page, and don't hide the changed content behind client-side JavaScript. None of it accelerates the re-rank stage itself.

Why haven't my rankings changed after I updated my website?

Most often it's simply too early — check the page's last crawl date in URL Inspection; if it's before your deploy, Google hasn't re-read the page. If the page has been re-indexed and rankings are still flat after about three weeks, that's a real signal the change wasn't competitively meaningful, not a measurement artifact.

---

The takeaway is simple and worth internalizing: shipping a change and seeing a ranking move are separated by a delay measured in weeks, and that delay is exactly why teams can't tell which of their commits actually drove their search results. If you want to see that attribution done automatically on your own repo and Search Console data, the Code Results beta is open.