Outdated website — when the calendar decides, not taste

A site does not age because it looks old. It ages because the things around it stop supporting it — browsers change their requirements, software versions lose support, rules come into force on set dates.

That is the difference that decides the budget. A redesign follows from what you dislike about the site and can be postponed. Modernisation follows from deadlines none of you set and cannot be — at most it can be missed and paid for more dearly later.

The calendar none of you set

Six deadlines. All come from outside, all have specific dates, none is about how the site looks.

Three of them are urgent, because they fall within the next fifteen months.

31 December 2026 — PHP 8.2 stops receiving security fixes. This deadline reaches the largest number of business sites, because WordPress runs on PHP and a great many company sites run on WordPress. After that date, according to the php.net schedule, new vulnerabilities in that version are simply not patched — not "patched more slowly", not patched. A year later, the same for PHP 8.3.

October 2026 — Chrome 154 turns on encrypted connections by default for everyone. A site without a certificate stops opening without an extra prompt to the user. We cover it in detail alongside SSL certificates.

15 March 2026 — the maximum certificate lifetime fell to 200 days, and in 2027 it drops to a hundred. That is already in force, and it means the end of the "upload a certificate once a year" model.

The fourth deadline, 28 June 2025, has already passed: the European Accessibility Act brought consumer-facing services into scope. Exactly who, and under what regime, we set out in the text on accessibility and WCAG.

What "outdated site" means once you stop guessing

"It looks old" is not a criterion, because it cannot be verified or priced. Four checks that take a quarter of an hour and answer yes or no.

Which software version it runs on. A question for your supplier or your hosting panel: which PHP version, which content management system version. If either is past a date on the timeline above, you have your answer and a deadline.

Whether it can be used on a phone. Not in a desktop preview — on your own phone, on mobile data. A form you can fill in without zooming, a menu that opens, images that do not push content off the screen.

Whether anyone at the firm can add a page without a developer. Ask them to do it in front of you. The difference between "theoretically possible" and "in practice nobody does it" surfaces in five minutes.

Whether the site passes a basic accessibility check. Keyboard operation, contrast, form field labels. For some firms this is now a requirement, not a nicety.

Four yeses mean modernisation can wait. One no on the first question means a date in the calendar.

How to check which version your site runs on

The whole calendar above rests on one thing most site owners do not know: which server software version serves their site. Checking takes a few minutes and needs nobody's help.

In the hosting panel. Almost every panel has a section for choosing the PHP version — "PHP settings", "PHP version", or buried in the domain configuration. You will see the version in use and the available ones. That is the list to compare against the timeline.

In the content management system. Popular systems show the environment version under site health or system information. Often the fastest route if you have no hosting access.

By asking hosting support. One sentence: "which PHP version serves my domain, and until when will it be available". The answer should arrive the same day.

Three possible answers and what each means:

• A version on the supported list, with a date in the future — nothing to do; come back six months before the deadline.
• A version past its end-of-support date — a task whose deadline has already passed. The longer it runs, the more it costs, for reasons below.
• Nobody can answer — a separate piece of information, and an answer too. It means nobody is minding this site, so the backups and the certificate probably are not being minded either.

Worth checking before any conversation about a quote. A supplier starts with that question anyway, and you will know whether the answer matches.

Modernisation and a redesign — where exactly the line runs

This distinction decides what you pay, so it is worth being clear about.

Modernisation replaces the wiring. A new software version, better performance, compliance with requirements, a tidied technical layer. The building stays the same — what changes is what you cannot see, and what stopped meeting the rules.

A redesign changes the layout and the façade. A different arrangement of content, a new look, a different customer path, sometimes a different technology from scratch. It starts from what you dislike, or from what is not selling.

In practice one is often the occasion for the other, and that makes sense: if the technical layer has to be touched anyway, this is the cheapest moment for changes planned regardless. The reverse order — a new look on an obsolete technical layer — means paying a second time in a year.

What modernisation does to your rankings and URLs

This is the first question that comes up once modernisation is set against a redesign, and the answer is reassuring — on one condition.

Modernisation by definition does not change URLs. Raising a software version, improving performance, meeting accessibility requirements: all of it happens underneath, and the address structure stays as it was. The risk of losing rankings — real, and nowhere larger than in a redesign — simply does not arise.

The condition: as long as nobody changes the URLs while they are at it. They do, surprisingly often, because modernisation becomes an occasion to "tidy up while we're here" — restructuring categories, shortening addresses, moving the blog to another directory. Each is already a redesign as far as a search engine is concerned, and needs address-for-address redirects.

Three things worth checking after every modernisation, ideally the same day:

• That the URLs have not changed — compare a few of the most visited pages before and after.
• That nothing has been blocked from indexing. Test environments block search engines as standard, and the setting can travel to production with everything else. The single most dangerous mistake here, because it is invisible on the site.
• That the site still returns correct response codes — rather than an error page with a success code.

A side effect that is usually positive: a faster site tends to be judged better on user experience. That is help at the level of settling a tie between two similar results, not a jump — but in that direction, not the opposite.

What actually happens when the deadline passes

One misconception worth defusing: on the day a software version loses support, nothing happens. The site keeps working, customers keep arriving, the form keeps sending messages. That is precisely why the deadline gets ignored for years.

The consequences arrive later, and in this order:

First the fixes stop. A vulnerability found after that date is described publicly, but no patch is made for your version. The information is open, so from that moment the advantage sits with the attacker — and grows every month instead of shrinking.

Then the extensions stop working. Plugin and theme authors test against supported versions. After a while, updating an extension requires a newer version than yours, so you are stuck on old versions of everything at once — the point at which modernisation gets more expensive, because several things have to be raised together.

Finally somebody else decides. At some point the host switches obsolete versions off, usually at short notice. Modernisation stops being a decision and becomes an incident to be cleared in a week — at the price and quality a scramble produces.

The practical conclusion: the cost of this work grows over time; it does not shrink. The opposite of a redesign, which can be postponed without consequence if the current site works.

Who does this — and how it differs from building a new site

It is not the same skill, though it is often sold as though it were.

Building a new site is work on a blank page. Modernisation is work on somebody else's code that nobody remembers, with undocumented dependencies. A supplier who answers a modernisation request by proposing to build everything from scratch is sometimes right — and sometimes simply does not want to go into somebody else's code. One question separates the two: ask them to point out specifically what cannot be saved, and why.

Three things worth asking before you commission it:

• Do you work on a copy or on the live site. The correct answer is a copy — a test environment where everything is tried before deployment.
• What does rolling back look like. "We have a backup" is not enough; you want to know how long a restore takes and who performs it.
• What will be written down at the end. A list of versions, credentials and dependencies makes the next modernisation cheaper. Its absence means that in two years somebody discovers all of it again from scratch, at your expense.

When the problem is the hosting

Sometimes modernisation cannot be done at all, and the cause lies outside the site.

Some cheaper packages pin one old server software version and do not allow it to be changed from the panel. It also happens that a newer version is formally available but switching it on breaks something else, because the rest of the environment stayed on the old configuration.

Checking takes a few minutes: in the hosting panel, find where a server software version can be chosen. If there is no such choice, or the newest option is already past its end-of-support date, you have your answer — and modernising the site takes a back seat to changing host.

It is the same situation as with certificates: a provider that does not let you choose a version, does not let you turn on automatic renewal, and charges for things that are normally free — costs more than the invoice suggests. The difference only shows when something has to change.

What modernisation actually covers

Scope varies, but the same set recurs. Split into what you can see and what you cannot — the second is usually the larger part of the bill, and the part worth asking about in a quote.

What you cannot see, and which is the heart of the work:

• Raising the server software and content management system versions, with everything that depends on them.
• Tidying and testing the backups — modernisation is the only moment anyone actually tests them.
• Performance work: images, caching, whatever loads for no reason.
• Meeting accessibility requirements to the extent they apply to your firm.
• The certificate and automatic renewal, if it currently runs by hand or not at all.

What you can see:

• Layout fixes on phones, usually forced by the template changing along the way.
• Forms — most often shortened, because somebody finally asks how many fields are really needed.
• Updates to content that has gone stale.

One thing worth asking the supplier while you are at it: what will be written down after the modernisation, so that in two years it can be repeated more cheaply. The list of versions, credentials and dependencies is part of the work, and often gets skipped.

What to write down so the next modernisation costs less

Modernisation comes round every two or three years, the length of a support window. The largest part of the bill for the second and third round is usually rediscovering what somebody already established once. One document, written on the day the work finishes, cuts that short.

What belongs in it:

• The versions of everything — server software, content management system, database. With end-of-support dates where they are known.
• A list of extensions marking which are critical and which could be removed. At the next version bump that is the first question, and usually nobody knows the answer.
• The places where something was worked around. Fixes made outside the normal mechanism disappear at the next update. Written down, they can be restored; not written down, they vanish along with the feature they served, and nobody knows why.
• Who holds which credentials — domain, hosting, system, analytics and the certificate account. Together with the email address the notifications go to.
• How to restore a backup — not only where it is, but who last did it and how long it took.

One page, half an hour at the end of the project. At the next modernisation it saves a day or two — the whole difference between planned work and discovering somebody else's code by the hour.

The order, if the budget only stretches to part of it

How long it takes and what it depends on

The honest answer: a technical modernisation of a typical company site is usually days rather than weeks — provided nothing turns into a surprise. There are two surprises, and both can be checked for in advance.

Unsupported extensions and themes. Raising a software version breaks whatever stopped being maintained. The more bolted-on pieces, the greater the chance one of them holds up the whole project.

Changes made "quickly" in the code. Fixes applied directly to files, outside the normal mechanism, disappear at the next update. Nobody remembers them until they are gone.

We give no figures, because our website cost report collects data on building sites, not on modernising them — and inventing a range would be exactly what we warn against elsewhere. Worth knowing, though: a modernisation quote approaching the price of a new site signals that the supplier sees the problem as deeper than it was described. The question then is "where", not "why so expensive".

What modernisation will not fix

This is the section the people selling it leave out of their own write-ups.

It will not fix the offer. A new software version and a tidy database will not make a proposition customers were not buying start to sell. Modernisation protects against an outage and against dropping out of the results. It does not replace marketing.

It will not bring traffic. A modernised site nobody visits is a site nobody visits, on a newer software version. Where people actually come from, and what you cannot see in that, we break down separately.

It will not settle your rankings. A faster and safer site helps, but that is help at the level of settling a tie between two similar results, not a lever.

So the honest summary is this: modernisation is a maintenance cost, not an investment in sales. You bear it for the same reason you replace the wiring in a building — not to bring in more customers, but so that the building can go on being used.