Chrome now ships every two weeks. What that changes for your website

On 8 September 2026, Chrome 153 ships to stable and the browser that renders roughly two-thirds of the world's web traffic starts updating every two weeks instead of every four. Most coverage of this has been written for browser engineers. This is the version for the people who own a business website and have to decide whether it changes anything about how their site is maintained.

What is actually changing on 8 September

Chrome has shipped a numbered milestone every four weeks since 2021, with separate security patches going out weekly since 2023. From Chrome 153 onward, the milestone itself moves to a fortnightly cadence across desktop, Android and iOS. The Dev and Canary channels are unchanged. Extended Stable, the slower channel aimed at enterprise IT and Chromium embedders, keeps its existing eight-week schedule.

Google's argument is that smaller, more frequent releases are less disruptive than larger, less frequent ones: when something regresses, there are fewer changes in the release to bisect, so the cause is found faster. That reasoning is sound, and it is the reason the honest answer to "should I panic" is no. But the same change has a second-order effect that gets much less attention, and it is the one that matters if you are not running a browser vendor's release engineering team.

The part that actually affects you: the warning window shrinks

When Chrome removes a web platform feature, the removal is telegraphed in advance. A deprecation warning surfaces in the Beta channel, and the actual removal lands a fixed number of milestones later. Because milestones now arrive twice as often, that fixed number of milestones is a shorter number of weeks. In practice a breaking API removal that used to give you about eight weeks between the first Beta warning and the code disappearing from your users' browsers now gives you about six.

Two weeks does not sound like much. It matters because of how most business websites are actually maintained: someone looks at the site properly once a quarter, or when something visibly breaks. Against a quarterly rhythm, an eight-week warning had a reasonable chance of landing inside a review window. A six-week warning frequently does not. The failure mode is not "Chrome broke my site", it is "Chrome told us, on schedule, in a channel nobody on our side reads."

What actually breaks when a browser updates

Browser regressions on ordinary marketing and ecommerce sites are not random. They cluster into a small number of mechanisms, and knowing which one you are looking at tells you who has to fix it.

Notice the pattern: the visible failures are the cheap ones. The expensive ones are silent, and two of the five sit in measurement rather than design. A site can lose weeks of clean conversion data to a storage policy change without a single page looking wrong, which is exactly the pattern we described when Shopify's checkout migration took tracking offline in a way that looked identical to a sales dip.

How often should you actually be testing now?

Doubling the release cadence does not mean doubling your QA. The right cadence depends on how much you would lose if the site were subtly broken for two weeks, and that varies enormously between a five-page brochure site and a store taking orders.

Should you move your team to Extended Stable?

No, unless you are an IT administrator managing browsers on employee machines. Extended Stable is a deployment channel for the browsers your staff use; it has no effect whatsoever on the version of Chrome your customers are running. Your customers are on Stable, and they will get a new milestone every two weeks whether you like it or not. Testing your public website against a slower channel than your visitors use would make your QA less representative, not more.

The channel that is genuinely useful to a website owner is Beta. It is where deprecation warnings surface first, and under the compressed schedule it is now the difference between six weeks of notice and none. Nobody needs to browse in it daily. Having one machine, or one automated test run, hitting your critical flows in Beta is enough.

A realistic browser regression drill

When something does break, the diagnostic sequence matters more than the fix, because most of the time spent on a browser regression is spent establishing that it is one.

1. Reproduce it in a second browser. If Safari and Firefox behave identically, it is your code or your host, not Chrome.
2. Reproduce it in Chrome with extensions disabled, in a private window. A surprising share of "Chrome broke it" reports are one user's extension.
3. Open the console and read it. Browser-driven failures almost always announce themselves there, in text, before anyone notices visually.
4. Check whether the failing element is yours or a vendor's. If it is a chat widget, review platform or booking embed, the fix belongs to that vendor and your job is to chase them, not to patch around it.
5. Check your analytics for the same date range. If a rendering bug started on a release date, the conversion data will usually show it before a human does.
6. Only then change code, and deploy the fix from version control, not by editing files on the live server, so the change is reversible. If your site has no version control, that is the more urgent problem.

Does this change what a website costs to maintain?

For most small and mid-sized business sites, no. The maintenance work that actually protects a site, keeping the CMS and plugins current, monitoring uptime, checking that forms and tracking still fire, keeping backups, was never scheduled around Chrome's release calendar, and it should not start being. A retainer priced against a four-week browser cycle was not really priced against that cycle at all.

What does change is the value of automation at the top end. If your site is a store or a booking system, a scripted test that walks the critical path and runs on a schedule was already worth having. At 26 releases a year rather than 13, the arithmetic gets more one-sided: the test costs the same to write and now covers twice as many opportunities for something to go quietly wrong. If you are budgeting website maintenance for 2027, that is the line item worth adding, not more manual checking.

Frequently asked questions

When does Chrome's two-week release cycle start?

It starts with the stable release of Chrome 153 on 8 September 2026. From that point, Chrome ships a new milestone to stable every two weeks instead of every four, across desktop, Android and iOS.

Will my website break because Chrome updates more often?

Almost certainly not on day one. Each release now contains fewer changes, so any individual update is less likely to change behaviour your site depends on. The real risk is cumulative rather than sudden: twice as many releases per year means twice as many opportunities for a small regression to go unnoticed on a site nobody checks between quarterly reviews.

What actually gets shorter under the new schedule?

The deprecation warning window. Chrome telegraphs feature removals a fixed number of milestones in advance, and because milestones now arrive twice as fast, the gap between a warning appearing in Beta and the removal reaching users compresses from roughly eight weeks to roughly six.

Do the Dev, Canary and Extended Stable channels change?

No. Dev and Canary keep their existing cadence, and Extended Stable, the slower channel for enterprise administrators and Chromium embedders, continues on its eight-week schedule.

Should I test my website against Extended Stable instead?

No. Extended Stable governs the browser your staff use, not the browser your customers use. Your visitors are on the Stable channel and will receive fortnightly updates regardless. Testing against a slower channel would make your QA less representative of real traffic, not more.

How often should a small business website be tested now?

Match the cadence to what a silent two-week failure would cost. A brochure site with no forms is fine on a quarterly check. A lead generation site should have someone submit a real test enquiry monthly and confirm it arrives. A store or booking system should have an automated test of the critical path running against every release.

The takeaway

Chrome shipping every two weeks is not an emergency, and treating it as one would waste money. It is a cadence change that quietly punishes one specific habit: maintaining a website on a quarterly rhythm while the platform underneath it moves on a fortnightly one. The fix is not more testing. It is testing the two or three journeys that actually make you money, on a schedule, and knowing within days rather than months when one of them stops working.