Does your website maintenance contract contain a clause like this? "QA will be performed on the latest versions of major browsers."
From this single sentence alone, it is unclear whether verification happens with every update or during monthly or quarterly inspections. Starting with version 153 on September 8, 2026, Chrome shortened its Stable release cycle from four weeks to two weeks.
If your contract stipulates verification for every release, the number of Chrome QA checkpoints will increase. However, this does not mean maintenance labor and fees automatically double. The required work changes depending on contract frequency, scope of changes, and the extent of automation.
What increased is the number of milestones, not the volume of risk
Let us clear up a misconception first. Just because updates are faster does not mean the probability of your site breaking has doubled.
The total volume of added features remains largely unchanged. What has changed is the time it takes for those features to arrive and the number of delivery checkpoints. The changes per release become smaller, while the frequency increases. Smaller changes per update tend to reduce the scale of any single incident.
On the other hand, verification work scales with frequency. This is where a gap in perception arises.
| What changed | Impact on operations |
|---|---|
| Update interval shortened to two weeks | Number of checkpoints doubles |
| Volume of change per update | Actually becomes smaller |
| Security updates | Handled separately as needed, as before |
In short, the work that increases is verifying that nothing is broken, not performing fixes themselves. Separating these two concepts reshapes how maintenance should be designed.
Do not attempt to check everything
A practical approach is to avoid applying the same verification process to every update. Divide your scope into the following three categories:
First, basic static pages. Include the display and links of representative pages in lightweight automated checks, and conduct visual inspections during updates that affect CSS or fonts. This does not mean static pages unconditionally require no verification.
Second, pages where breakage halts revenue. These include contact forms, quote calculators, checkout flows, and logins. Here, instead of increasing check frequency, make the decision to switch from human inspection to automated execution. Build a system that verifies delivery paths using test recipient addresses or staging environments without cluttering actual sales notifications or customer registrations. Use test mode for payments.
Third, areas using new visual styling or cutting-edge features. This applies to recently implemented animations or layouts that depend on newer specifications. Have your agency provide an inventory of these areas.
Enterprise slow channels are not a solution
A proposal that inevitably surfaces here is to distribute a slower update channel internally. Chrome offers an enterprise channel that updates every eight weeks.
However, this only applies to internal company PCs and has no bearing on customers visiting your website. Even if you pin internal devices to a slow channel, visitors' browsers will update every two weeks. In fact, you run the risk of checking exclusively against an outdated internal environment and falsely concluding there are no issues.
Please design internal device update policies and website QA policies as separate matters. Conflating the two creates the worst-case scenario: bugs that are invisible from inside your company.
Enable detection before verification
When update frequency rises, what truly delivers results is not increasing manual verification rounds, but having a mechanism to detect when something breaks.
Even if a person checks every two weeks, if an issue occurs the following day, it will go unnoticed for 13 days. Conversely, monitoring inquiry trends and error rates provides clues to anomalies. However, on sites with low baseline volume, zero inquiries on a given day can be normal. Combine this with test form submissions and delivery monitoring.
At minimum, the following two items are worth having in place:
- Trends in inquiries and document downloads. Without knowing baseline levels, you cannot notice a decline. We summarized typical examples of missing metrics in Are You Properly Measuring the Results of Your Commissioned Website?
- Notifications for errors occurring in the browser. Malfunctions that occur on visitors' screens do not leave traces in server-side logs
These two measures complement periodic QA. Attempting to scale up manual human effort alongside browser release cycles leads to continuously climbing costs while incident discovery remains sluggish.
The same debate is occurring around programming languages and frameworks. We also covered what to establish when update frequencies accelerate in Node.js Moves to an Annual Major Release.
What to verify in contracts and estimates
If you currently have a maintenance contract or are about to enter into one, please check the following three points:
- Is the scope of QA fixed to "the latest version"? Redefine target browsers and verification frequency separately from release cycles. "Once per quarter on current Stable versions of major browsers" aligns much better with practical reality.
- Are the target pages specifically identified? Beyond simply writing "all pages," explicitly specify verification scope and automation boundaries. Name the key pages directly tied to revenue.
- Is there justification for price increases cited as being due to increased check frequency? Even if the frequency doubles, automated portions should not double in cost. We outlined our thinking on reviewing maintenance fee breakdowns in When the Reason for a Maintenance Price Hike Was 'Surging CI Costs'.
We previously covered what should be included in maintenance contracts in the first place in It Does Not End with Delivery. What happens when websites are neglected is detailed in Why 'Build and Forget' Websites Are Risky.
What to do next
First, open your maintenance contract and re-read the clause regarding QA. If it only mentions "latest versions," make it concrete by clarifying when and what is contracted to be checked.
Next, identify three pages that would cause serious problems if broken, and communicate them to your web agency. Compared to a contract attempting to protect all pages equally, an agreement that tests these three pages automatically every day delivers lower risk for the same budget. Rather than chasing browser releases, it is faster to work backward from what would cripple your business if halted.
At GleamHub, we assist with reviewing website maintenance scopes, automating QA, and handling website redesigns. Because the required scope of verification varies depending on site structure and features, we provide individual estimates tailored to your requirements. Please reach out to us via Contact Us.
