What happens if you don't update WordPress for a year

Usually nothing you can see, at first. The site loads and the pages look the same. Underneath, known security holes pile up in the plugins, WordPress and PHP drop out of support, and every month the eventual catch-up gets harder. The risk is not that the site stops working on its own. It is that someone finds one of those known holes before you do.

Here is what actually changes over a year, and what to do if your site is already behind.

How often does WordPress change?

More often than most people expect. WordPress is planning three major releases in 2026, roughly one every four months, and the most recent version at the time of writing is 7.1.2, released on 22 September 2026 (WordPress, releases; 2026 release schedule). Between the major versions come smaller maintenance and security releases, often a few weeks apart.

Plugins and themes update on their own schedules, which for a site with 20 or 30 plugins means something new almost every week.

What goes wrong when nobody updates?

Known holes stay open

Most security problems on WordPress sites are not in WordPress itself. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and six in core. For the vulnerabilities attackers used most heavily, the median time from public disclosure to mass exploitation was five hours (Patchstack, State of WordPress Security in 2026).

Once a vulnerability is public, automated attacks scan for sites that have not updated. A year without updates means a year of those, left open.

WordPress falls out of support

WordPress officially supports only its latest version. Fixes for older versions are sent “as a courtesy”, and the project has been steadily reducing how far back those courtesy fixes go (WordPress, security). A site that is one or two major versions behind is relying on goodwill.

PHP expires underneath it

WordPress runs on PHP, which has a fixed support timetable. PHP 8.1 stopped receiving security fixes on 31 December 2025; PHP 8.2 stops on 31 December 2026 (php.net, supported versions). WordPress’s recommended version is 8.3, and it warns administrators on the dashboard and in Site Health when the server is behind (WordPress, update PHP). Moving to a newer PHP can break old plugins, which is one more reason not to let them fall behind.

Plugins disappear quietly

When a plugin is closed in the WordPress plugin directory, for a security issue, a guideline problem, or because its author gave up, it can no longer be downloaded, and the directory page shows a notice (WordPress, plugin alerts and warnings). Sites that already have it installed keep running it, and nothing guarantees that the owner will be told. Unless someone checks, an abandoned plugin can sit on a site for years.

What happens if the site is hacked?

Often the owner is the last to know. Hacked sites are commonly used to send spam, host hidden pages or redirect visitors elsewhere, while the home page looks normal.

When Google detects it, pages can show a warning in search results, or visitors see a full-page browser warning before the site loads. After the problem is fixed, the owner has to request a review, which Google says “can take several days or weeks” (Google, security issues report). For an association in renewal season, that is weeks of members being told your site is dangerous.

The Canadian Centre for Cyber Security’s advice for organizations whose site has been defaced is practical: contact the host, put up a maintenance page, restore from a clean backup, and tell the people affected. Its prevention advice starts with the same thing as ours: keep plug-ins updated, and back up before updating (Cyber Centre, website defacement).

How often should WordPress be updated?

WordPress minor and security releases install on their own by default on most sites. Leave that on.
Plugins and themes should be checked at least weekly and updated once you are confident they will not break anything, sooner when an update fixes a security issue.
Major WordPress versions should be applied within weeks of release, after a backup and a check of the plugins that matter most.
PHP should be moved to a supported version before its end-of-life date, tested first.

The common thread is a backup before every round of updates, and someone checking the site afterwards.

Our site has not been updated in a year. What now?

Do not click “update all”. Updating a year of changes at once on a live site is how sites break.

Take a full backup, files and database, and keep a copy off the host.
Make a staging copy if your host offers one, and update there first.
Review the plugins. Remove the ones you do not use, and replace any that have been closed or abandoned.
Update in stages: WordPress core, then plugins one at a time, then the theme, checking the site after each.
Move PHP to a supported version once everything else is current.
Put someone in charge of doing this every month, so it does not happen again.

If that list looks like more than your team can take on, it is exactly what a care plan is for. See What a website care plan includes, and what it does not.

Disclosure: bringing out-of-date sites up to date is part of how we start Managed Care.

If your site is behind and you would like a second opinion, schedule a discussion.

Sources (checked 30 September 2026)