Website Change Freeze: Finish the Work in October, Then Leave Your Site Alone for Christmas

Stop changing your website in December. Every plugin you add, every theme update you click, every "quick tweak" to the checkout between Black Friday and Christmas Eve is a risk taken at the exact moment your site can least afford to carry it. Do the risky work now, in October, and then put a change freeze in place until January.

That is not caution for its own sake. It is how every serious operations team on the planet handles its busiest period, and there is no good reason a small business should behave differently.

Most outages start with somebody changing something

Google's Site Reliability Engineering book, written by the people who run some of the largest systems in existence, puts it plainly: roughly 70% of their outages are caused by changes to a live system ^[1]. That figure comes from Google's own environment, so treat it as a strong indication rather than a law of nature. Your shop is not Google. But the pattern holds at every scale I have worked at.

Sites rarely fall over on their own. They fall over after a deployment.

A plugin update changes how the basket calculates shipping. A new theme version moves the "Add to cart" button below the fold on mobile. A marketing plugin someone installed on a Sunday evening conflicts with the payment gateway, and the checkout throws an error that nobody sees because the owner is not shopping on their own site at 9pm. By the time anyone noticed, the orders that would have come in that evening have gone somewhere else.

For the owner-operator, that means one thing. The more you change, the more chances you give your site to break, and December is the month where a broken site costs the most.

Why the timing matters more than the change

Online trade in Ireland is not spread evenly across the year. According to the Central Statistics Office, online sales accounted for around 7% of turnover across Irish-registered businesses in November 2025, falling to roughly 6.5% in December ^[2]. Strip out the motor trade and the November figure rises to a little over 9%. Those are averages across every sector, so a gift shop or online toy retailer will be far more concentrated in that window than an accountant.

Two things stand out. November, with Black Friday in it, is the online peak, not December. And the freeze needs to be in place before the last week of November, not after it.

Consider a typical case. An online toy shop in Cavan does a large share of its year between mid-November and the third week of December. In early December the owner decides the product pages "could look better" and installs a new gallery plugin straight onto the production environment. It works on the desktop in the back office. On older phones it stalls the page while it loads every product image at full size. Nothing breaks loudly. Sales just get quieter, and the owner spends a week blaming the weather before anyone looks at the site.

That is the version of this failure nobody writes about. Not the dramatic crash. The slow leak during the weeks that pay for January.

What a change freeze covers, and what it does not

A change freeze is not "never touch the website". It is a decision about which kinds of change are allowed during a defined window. The distinction that matters is between changing how the site works and changing what the site says.

Type of change	During the freeze	Why
New plugins, redesigns, new features	Frozen	Highest risk, lowest urgency
Routine plugin and theme updates	Frozen, unless security-related	Untested code arriving mid-peak
Security patches	Apply, with a snapshot first	Delay is more dangerous than the update
Prices, cut-off dates, opening hours, stock	Keep updating	Content, not code

New plugins, redesigns and new features

These wait until January. A new booking plugin, a different checkout layout, a colour scheme refresh: none of them is urgent, and every one of them introduces new code and new dependencies. If the idea is good in December it will still be good in the second week of January, when you have time to test it properly.

Routine plugin and theme updates

Most plugin updates are feature releases and minor fixes. Since WordPress 5.5, site administrators can switch automatic updates on plugin by plugin and theme by theme, and by default WordPress checks for them twice a day ^[3]. That is sensible for most of the year. During the freeze, it means code you have never seen can land on your production environment at a time you did not choose. Switch automatic updates off for anything that is not security-critical, note the date, and switch them back on in January. The same WordPress documentation recommends making sure you can roll back before enabling auto-updates at all, which tells you something about how often they misbehave.

The exception: security patches cannot sit until January

A freeze has one honest limitation, and it is a big one. It cannot protect you from a vulnerability that is disclosed while you are frozen.

Patchstack's State of WordPress Security in 2026 report counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, an increase of around 42% on the year before, with roughly 9 in 10 of them found in plugins ^[4]. The figure that should concern any operator is speed: Patchstack puts the weighted median time to first exploitation of heavily targeted vulnerabilities at about five hours, with around half of high-impact flaws exploited within a day. Their numbers come from their own monitoring, and other researchers count differently, but the direction is not in dispute.

Five hours is not long enough to wait for January. If a plugin you rely on releases a security fix during the freeze, you apply it. The freeze changes how you apply it, not whether.

The procedure is simple. Take a snapshot first. Apply the patch. Verify the pages that make you money: the homepage, a product or service page, the contact form, the basket and the checkout. If anything has changed, roll back to the snapshot and ring your host. A pre-update snapshot taken automatically before the change turns a failed patch into a ten-minute inconvenience instead of an evening of guesswork.

Content keeps moving, and that is fine

The freeze is about code. Your words, prices and dates should keep changing as often as the business needs them to.

Delivery cut-off dates are the obvious example. In 2025 An Post set its last recommended posting date for parcels within Ireland at 16 December, and noted on its own Christmas page that the date had been moved earlier than originally planned because of unprecedented volumes ^[5]. A shop that had published a later date on its delivery page needed to change it, quickly, mid-peak. That is a content edit. It carries almost no risk, and it should never be blocked by a freeze.

The same goes for holiday opening hours, out-of-stock notices, a banner announcing that orders placed after a given date will ship in January, and price changes for a sale. Edit the page, preview it, publish it. You are not changing the machinery underneath.

One caution worth stating. Some "content" edits are code edits in disguise. Pasting a tracking snippet into a header, embedding a third-party countdown widget, or switching on a new page-builder block all add code to the site. If it involves copying in something you do not fully understand, treat it as a code change and leave it until January.

October is when the risky work belongs

If you are going to change anything structural before Christmas, the window is now. Six to eight weeks gives you time to deploy a change, watch how it behaves under normal traffic, and roll it back without pressure if it misbehaves.

Early in my career I approved what looked like a minor theme update on a retail site in the second week of December, because the changelog was short and harmless-looking. It altered how the basket page loaded scripts, and we spent an evening rolling it back. The changelog was accurate. It simply had never been tested against that site, and I had not given it the chance to be. I have not approved a non-security change in December since.

The October work list for most small businesses is short:

• Apply all pending updates now. Get every plugin, theme and WordPress itself current while the stakes are low, so the freeze starts from a clean, known state.
• Remove what you do not use. Every deactivated plugin still sitting on the site is code you are responsible for. Delete it.
• Test the full buying journey on a phone. Not the homepage. The whole route from a product page to a completed order or a sent enquiry form.
• Prepare your Christmas pages in advance. Delivery dates, holiday hours, gift voucher pages and any sale pages can be built now and published later.
• Verify a restore actually works. A backup you have never restored is a theory, not a backup, and the fundamentals of WordPress backups and security are worth reviewing before the season rather than during it.

What a platform should do for you during the freeze

The owner sets the policy. The hosting platform decides how painful it is to follow.

A platform that supports a sensible freeze should give you somewhere other than production to try changes, so that anything you are curious about can be tested without touching the site customers use. It should take a restore point automatically before any update, because nobody remembers to do it manually at 10pm. It should keep regular backups that can be restored in one step, not through a support ticket that sits in a queue. It should cache pages properly so a spike in Black Friday traffic does not slow the checkout for everyone. And there should be a real person to ring when something does go wrong, in your time zone, during your trading hours.

Web60 is built around that list. Every site gets a one-click staging environment, so you can clone production and try a plugin there instead. Pre-update and pre-restore safety snapshots are taken automatically, alongside nightly backups with one-click restore and manual backups on demand. The stack runs Nginx with Redis object caching and FastCGI page caching on Irish infrastructure, so the pages a shopper hits during a promotion are served from cache instead of being rebuilt on every visit. Support comes from an Irish-based team of real people.

All of it is part of Web60's all-inclusive managed WordPress platform at €60 a year, with no per-feature charges for staging or backups. If you are planning a site from scratch for next year's trading, the AI builder will have a full WordPress site in front of you in about a minute, which leaves the whole of October for testing rather than building.

To be fair about the limits of this advice: a large retailer with an in-house development team, automated test suites and a proper deployment pipeline can ship changes safely in mid-December, and enterprise managed hosts are genuinely built for that kind of operation. That is a different business with different tooling. Equally, if your site is a simple brochure for a trade that does not see a Christmas peak, a freeze matters far less, and you can relax the rules accordingly. For a small business doing a large share of its year online between November and Christmas, the freeze is the cheapest insurance available.

How to Set a Christmas Change Freeze in Four Steps

1. Deploy everything structural by mid-November. Finish updates, plugin removals and design changes early enough to watch them under normal traffic for a few weeks.
2. Disable non-security auto-updates. Switch off automatic updates for plugins and themes that are not security-critical, and write down the date you need to switch them back on.
3. Verify your rollback path. Restore a backup to staging once, so you know exactly how long it takes and what it looks like before you ever need it.
4. Patch security issues with a snapshot first. Take a snapshot, apply the fix, test the pages that take money, and roll back immediately if anything has changed.

Leave it alone and let it sell

None of this is complicated. Most of the risk in December comes from well-meant changes made at the wrong time, and a freeze removes that risk at almost no cost. Do the building and the tidying in October. Keep your dates, prices and hours current through the season. Patch security flaws properly, with a snapshot behind you. Then leave the site to do what you built it for, and pick up the wish list again in January, when a broken page costs you an afternoon instead of a Christmas.

Frequently Asked Questions

What is a website change freeze?

A change freeze is a set period, usually around a busy trading season, during which you stop making structural changes to your website. New plugins, redesigns and routine updates wait until the period ends. Content updates such as prices, opening hours and delivery dates continue as normal, and security patches are still applied.

When should a small business start a Christmas change freeze?

For most online sellers, before the last week of November, so the freeze covers Black Friday as well as the run-up to Christmas. CSO figures show the share of turnover coming from online sales was higher in November 2025 than in December, so starting in December misses the busiest online weeks.

Should I turn off WordPress automatic updates over Christmas?

Turn off automatic updates for plugins and themes that are not security-related, and keep a note to switch them back on in January. Do not ignore security releases. Apply those manually after taking a snapshot, then check your checkout and contact forms before moving on.

What if something breaks during the freeze anyway?

Roll back first and investigate second. Restore the snapshot or most recent backup taken before the change, confirm the site is working, then contact your host to find out what went wrong. Trying to fix a broken production site live, during peak trade, usually makes the outage longer.

Sources