WordPress maintenance
At Sharpness Solutions GmbH in Oldenburg, WordPress maintenance means core, plugin and theme updates in a controlled order, first on a staging copy, then live. Plus backups whose restore has been tested, monitoring, TLS and a PHP version that still receives security updates. The current version is WordPress 7.0.3 from 6 August 2026; WordPress 7.1 is announced for 19 August 2026. We agree response times in a service level range from 24 down to 2 hours — without an agreement, our basic commitment applies. We support installations on our own servers in Germany and on third-party hosting. Last updated: 17 August 2026. Telephone 0441 21 21 63 0, Mon–Fri 9:00–16:00.
Very few enquiries about WordPress maintenance begin with an attack. They begin with somebody opening the plugin overview and seeing twelve pending updates there, without knowing which of them can be installed safely. The scale behind this is documented: in its whitepaper „State of WordPress Security in 2026", Patchstack counts 11,334 new vulnerabilities in the WordPress environment for the year 2025, 42 per cent more than the year before. 91 per cent of them were in plugins, 9 per cent in themes. The WordPress core itself accounted for six reports in the whole year, all of them low priority (retrieved 17 August 2026). That is the real message: WordPress is maintained. The plugin environment is not necessarily.
The core has updated itself, because WordPress has done this automatically with minor releases since version 3.7. The plugins have not. The last deliberate change to the installation is so long ago that nobody remembers which plugin is there for what, and which one only sits deactivated in the directory. As long as the front end looks normal, nobody notices — not even the management, who use the website every day.
A plugin writes an archive every night, and the hosting provider advertises daily snapshots. Whether a working installation with a functioning login, media library and mail delivery can be built from it has never been tried. An untested backup is not a backup. Experience shows this on the day you need it, and then it is no longer good news but a second incident.
Search Console reports indexed pages that do not exist. Mails to customers land in spam, although nothing has changed. The hosting provider writes about outgoing mail traffic. In the browser, by contrast, everything looks unremarkable. That is exactly how the common WordPress compromises behave — they are not aimed at being seen, but at staying unnoticed.
The hosting provider is responsible for the server, the plugin vendor for their plugin, and the developer from back then does not answer. In between sits the application, and that is where the faults happen. What is missing is not another responsible party, but an agreed response time and an address you can write to without first requesting a quote.
WordPress maintenance consists of four kinds of work that are only loosely connected: core updates, plugin and theme maintenance, maintenance of the underlying platform, and support for the editorial team. For the first two, the order is decisive. Before the core update comes the check whether the plugins in use support the target version — not after it. In the maintenance window we therefore work in steps: take a backup, bring the staging copy up to the live state, update the plugins individually or in small groups, then the core, then rebuild the theme. Anyone who instead clicks „Update all" once has twelve suspects and no findings if something goes wrong. The rollback route is defined before the window, not searched for during the incident.
Backups are the part of maintenance with the most trust and the least checking. A backup consists of three things: the database dump, the wp-content directory with uploads, themes and plugins, and the wp-config.php. A restore test involves more: the archive is actually restored on a staging environment, and then the login, the media library, a form submission and the home page are checked. Only then is it proven that the chain works. We set the retention period in writing, keep the backups separate from the production system and log every test. A backup that sits on the same server as the installation covers technical failures, but not a compromise.
The underlying platform ages independently of WordPress and is therefore regularly overlooked. On its own requirements page, WordPress recommends PHP 8.3 or newer and MariaDB from 10.11 or MySQL from 8.0 (retrieved 17 August 2026). The technical minimum values are much lower at PHP 7.4 and MySQL 5.5.5 — these are versions that no longer receive security updates themselves, and WordPress points this out explicitly on the same page. This part of the work also covers TLS certificates and their renewal, the question of whether WP-Cron runs through page views or through a system cron, and mail delivery: wp_mail() sends through PHPMailer, by default through the PHP function mail(), which regularly fails with today's recipients — an authenticated SMTP route with SPF, DKIM and DMARC belongs in the maintenance, not in a separate project. Monitoring therefore means more than a ping for us: availability, status codes, certificate validity, cron jobs, mail delivery and error rates in the log.
The WordPress core is not the problem child, and it helps nobody to make it one. Minor releases have been distributed automatically since version 3.7, security fixes with a forced update if necessary — that is how it worked with 7.0.2 on 17 July 2026. Of the 11,334 vulnerabilities that Patchstack counts for 2025 in the WordPress environment, 91 per cent were in plugins and 9 per cent in themes; the core accounted for six reports in the whole year, all of them low priority. 1,966 reports, that is 17 per cent, were rated high, which means: with a realistic prospect of being exploited in automated mass attacks. This does not mean that nothing happens in the core — 7.0.3 from 6 August 2026 brought around a dozen security corrections at once, some of them to code that reaches back into older main versions. The difference lies in the route: with the core, the fix appears together with the report and is distributed automatically. Anyone who talks about WordPress security and talks about core versions is talking about the smaller part of the problem.
The most uncomfortable figure from the same report for day-to-day operation: for 46 per cent of the vulnerabilities, no patch was available at the time of publication. For a maintenance window this means that „wait until the update arrives" is not a strategy. There are then three options — switch the function off temporarily, replace the affected component, or block the attack route further upstream. Which of these works is decided by the specific case. On top of this comes the structural problem of unmaintained extensions. WordPress.org puts a notice on the plugin page when an extension has not been tested with the last three main versions. This notice depends on the „Tested up to" field in the readme.txt — a developer can remove it without touching a single line of code. As a warning signal it is useful; as an approval it is worth nothing.
For a plugin without a maintainer there are four ways forward, and we name them one by one: use a maintained alternative, move the function into your own theme, take over the code yourself and maintain it further, or drop the function because nobody uses it anyway. The last case happens more often than people think. What does not belong here: replacing every plugin across the board that has had no release for a year. A small helper plugin whose code you can read in one sitting is a different risk from a form or shop plugin with its own database table and access to order data. We base the assessment on the code, not on the date. If the outcome is a custom development, that is a project of its own — there is more about this on our page on WordPress plugins and extensions.
With a system that does not update itself, you notice the standstill at some point. WordPress, by contrast, moves even when nobody is looking. Minor releases have arrived automatically since 3.7. Since version 5.6, new installations additionally have automatic updates for major releases switched on by default, provided WordPress does not detect a version control checkout; existing installations keep the old behaviour until an administrator, a constant or a filter changes it. In practice this means: some installations have moved from 6.x to 7.0 without anybody making a decision. The core is therefore up to date. The plugins, the theme and the custom code are not — and no automatic process checks whether they still fit together.
Where this breaks is not visible from outside. WordPress 7.1 is announced for 19 August 2026 and brings three breaking points that mainly affect the back end and the editor. First: the post editor will then always run in an iframe — regardless of the theme type, the block API version of the registered blocks and the blocks used in the content. Code that accesses the global document or window no longer finds the editor content there; the route runs through ownerDocument and its defaultView on an element in the canvas, and event listeners through useRefEffect. Second: in the list tables, the leading th with scope="row" moves from the checkbox column to the title column — the checkbox cell becomes a td, the title cell a th with aria-label. This is markup that has been essentially unchanged there since 2010; extensions that select on th.check-column or on th input[type="checkbox"] will find nothing. Third: the __next40pxDefaultSize property has become ineffective, and form elements render at 40 pixels unconditionally — even __next40pxDefaultSize={ false } no longer switches back to 36 pixels. One widespread misunderstanding should be corrected: React 19 is not coming in 7.1. The upgrade was withdrawn after incompatibilities appeared between the old and the new React version and in the way plugins include React. 7.1 stays on React 18.3; Gutenberg offers an experimental flag for testing. What the step itself means in terms of work is on our page about the WordPress update to 7.1 — here we are looking at the consequences for ongoing operation.
These errors affect editors, not visitors — and editors often do not report them but work around them. The silent failures in operation behave in the same way: the mail delivery of the contact form fails, but the thank-you page appears anyway. WP-Cron no longer runs, so scheduled posts do not appear and backups do not start. A redirect plugin loses its table, and old URLs end in a 404. All of this lets a website look normal. That is why maintenance does not check whether the home page loads, but the functions that money or enquiries depend on. And that is why the sentence „it works, though" is not a finding with WordPress, but an assumption.
A compromised WordPress is rarely recognisable by its appearance. The typical patterns are built to be inconspicuous: redirects that only trigger with a search engine referrer or with certain user agents, while the direct request looks normal. Links to third-party sites inserted into the footer or into post content, pushed out of view with CSS. Mail sent through the server until the IP address lands on blocklists and your own business mail no longer arrives. Plus the traces you have to look for: PHP files under wp-content/uploads, an unexpected wp-content/mu-plugins directory whose contents WordPress loads without activation, obfuscated code at the beginning of functions.php, an administrator account with an unremarkable name and a recent registration date, an additional cron entry. In practice the first indication comes from outside: from Search Console, from the hosting provider, or from a customer whose virus scanner raises an alert.
The order of steps in a suspected case is fixed, because otherwise the wrong things happen first under time pressure. First: put the installation into maintenance mode or take it off the network. Second: save a snapshot of the compromised state instead of overwriting it — it is the only basis for the question of what happened, and, if a report to the supervisory authority is needed, the only evidence. Third: withdraw access. Passwords of all editorial and administrator accounts, application passwords, database users, SFTP and SSH keys, plus the salts and keys in the wp-config.php, which ends all existing sessions. Fourth: take stock against a known state — compare core files and plugins against the originals, and go through the user list, the cron entries and the scheduled tasks. Only after that is the site restored or rebuilt, and the content is taken over, not the files.
A cleanup without clarifying the cause is pointless, and an uncomfortable limitation belongs here: on an installation that has not been maintained for years and whose logs have rotated, the entry route often can no longer be determined. We say so in that case, instead of selling an assumption as a finding. The consequence is a clean rebuild on a current basis with the content taken over, because that is the only way to know what is on the system — and not a second cleaning run after which the same redirects reappear in four weeks. If personal data is affected, the 72-hour reporting period under Article 33 GDPR applies; whether a report is necessary is assessed by your legal advisers, not by us. We can be reached Mon–Fri 9:00–16:00, outside these hours only with an agreed on-call service.
At Sharpness a maintenance contract consists of a fixed part and an agreed part. Fixed are: watching the security reports for the core, plugins and theme, including an assessment of whether your installation is affected; updates on staging first, then live; backups with a documented restore test; maintenance of PHP, the database, TLS and mail delivery; monitoring; support for the editorial team; and a log of the work carried out that you can present to a data protection officer or in an audit. What is agreed is the response time. There are four tiers for this: BASIC with 24 hours, STANDARD with 8 hours, ADVANCED with 4 hours, PREMIUM with 2 hours — each as a monthly flat rate net per project. We name the flat rate in the quotation, not on a website, because it depends on the scope of the installation. Without an agreement our basic commitment applies: processing in order of arrival within 48 hours during business hours, Mon–Fri 9:00–16:00.
Not included in ongoing maintenance are projects that need their own quotation. This includes catching up an installation that has not been touched for years: that is not a maintenance window but a project with an inventory, plugin replacements and test runs — you can read about it on our page on WordPress updates. The same applies to redesigns, new functions and the development of your own plugins and Gutenberg blocks. Regular version steps on a maintained system, for example from 7.0 to 7.1, are part of the maintenance. This distinction sounds like less service than with providers who include everything. It is more honest: anyone who names a flat price for an unknown backlog builds in a surcharge that you pay for every month.
Operation runs on our own servers in Germany — Proxmox cluster, server location Germany — or on your existing hosting. Both work. On third-party infrastructure we need SSH access, a usable deployment route, a staging environment or the option to create one, and access to the backups. If that is missing, every maintenance window becomes more expensive than a migration, and we say so in advance. We set up the ongoing support so that you can end it: access details and licences in your company's name, domains in your name, theme code in your repository, the installation documented. And if a maintenance contract does not pay off for you — a small company website with four standard plugins on decent hosting that you click through yourself every month — we say that too. A contract that only sells peace of mind does not last long.
Process
Send us the domain and, if available, back end access. You get a free written initial assessment of the version, plugin inventory, PHP status and backup situation — before any contract, and also if you then place the order elsewhere. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telephone 0441 21 21 63 0, info@sharpness.de, Mon–Fri 9:00–16:00. Support is provided remotely throughout Germany, with on-site appointments in Oldenburg and the north-west German region.
You describe the situation, and we clarify what is there: WordPress version, hosting, who has maintained it so far, whether there is a repository. What we need is an administrator account in the back end, SSH or SFTP access, database access and, if possible, the domain and DNS administration. If the previous service provider does not respond, we request the access details ourselves — you do not have to have an uncomfortable conversation.
We look at the core version, the plugin and theme inventory, custom code in the theme, the PHP and database version, the user accounts and the wp-content directory — including uploads and mu-plugins. The result is a written assessment: what is running, what is open, what has to happen first. If we find traces of a compromise, that is not a maintenance case but a separate quotation.
Before a maintenance rhythm makes sense, the starting point is put in order: remove deactivated and duplicate plugins, replace unmaintained ones or move their function into the theme, raise the PHP version, check TLS and redirects, move mail delivery to authenticated SMTP, switch WP-Cron to a system cron. Which of these is necessary is clear after step 02 and not before.
We set up a staging environment and run the first complete update pass there. Whatever breaks, breaks on a copy. In the same step the backup is not only set up but restored: login, media library, form submission, home page. Only then is the rollback route proven instead of claimed.
Now the response time can be chosen sensibly: BASIC 24 hours, STANDARD 8 hours, ADVANCED 4 hours, PREMIUM 2 hours, as a monthly flat rate net per project. We say which tier fits your website, and we also name the case in which the smallest one is enough. On-call service outside business hours is agreed explicitly or does not apply.
After that the ongoing support runs in the agreed rhythm: assess security reports, test and install updates, check backups, evaluate the monitoring, answer questions from the editorial team, log the work. You write to the same address and reach the same contact person as in the initial discussion, not a shared mailbox.
Projects on this system
A selection — not the full client list.
Included are watching and assessing the security reports for the core, plugins and theme, updates on staging first and then live, plugin and theme maintenance, maintenance of PHP, the database, TLS and mail delivery, backups with a restore test, monitoring, support for the editorial team and a log of the work. Regular version steps on a maintained system, for example from 7.0 to 7.1, are part of it. Not included are redesigns, new functions, the development of your own plugins and blocks, and catching up an installation that has not been touched for years — that is a separate project with its own planning.
WordPress has updated minor releases automatically since version 3.7, and since version 5.6 major releases are switched on by default for new installations, provided no version control checkout is detected; existing installations keep the old behaviour. What is automated is the core. What is not automated is the question of whether the plugins, the theme and the custom code still fit the new version. That is exactly where the risk sits: of the 11,334 vulnerabilities that Patchstack counts for 2025 in the WordPress environment, 91 per cent were in plugins and 9 per cent in themes; the core accounted for six reports in the whole year. Maintenance means checking the part that no automatic process checks.
At Sharpness, WordPress maintenance is billed as a monthly flat rate net per project, tiered by the agreed response time: BASIC 24 hours, STANDARD 8 hours, ADVANCED 4 hours, PREMIUM 2 hours. We name the price in the quotation and not on this page, because it depends on figures that can be checked: the number and type of plugins, the amount of custom code in the theme, whether hosting is included, whether several installations are supported. Anyone who names a monthly price without looking into the installation calculates an average that you help pay for. The initial assessment based on the domain and back end access is free of charge.
The response time is the time until somebody starts work — not the time until the problem is solved. There are four tiers: BASIC 24 hours for systems where an outage delays work but does not cost revenue; STANDARD 8 hours for websites in day-to-day business; ADVANCED 4 hours for installations with connected systems; PREMIUM 2 hours for systems where every hour of standstill costs money directly. Each tier applies only once the agreement is in place. Without it our basic commitment applies: processing in order of arrival within 48 hours during business hours, Mon–Fri 9:00–16:00. Cover outside these hours requires an explicitly agreed on-call service.
The assessment starts on the day of the report: we check whether the version and configuration named affect your installation, because many plugin vulnerabilities only apply with certain settings or from a certain user role upwards. Then comes the test run on staging, then the deployment. How quickly this has to happen depending on the severity is set out in the agreed service level tier. One special case is more common than people think: according to Patchstack, no patch was available at the time of publication for 46 per cent of the vulnerabilities published in 2025. In that case the function is switched off, the component is replaced, or the attack route is blocked further upstream.
For an extension without a maintainer there are four ways forward: use a maintained alternative, move the function into your own theme, take over the code and maintain it yourself, or drop the function because nobody uses it. Which way is cheaper depends on the range of functions. The notice on WordPress.org that a plugin has not been tested with the last three main versions is only a warning signal: it depends on the „Tested up to" field in the readme.txt and can be changed without touching a single line of code. We base our assessment on the code, not on the date — a small helper plugin is a different risk from a form plugin with access to customer data.
Rarely by the appearance of the website. Typical are redirects that only trigger with a search engine referrer or with certain user agents, while the direct request looks normal; links to third-party sites hidden with CSS; and mail sent through the server until the IP address lands on blocklists and your own business mail no longer arrives. You can check for PHP files under wp-content/uploads, an unexpected wp-content/mu-plugins directory, obfuscated code at the beginning of functions.php, new administrator accounts and additional cron entries. In practice the first indication comes from outside: from Search Console, from the hosting provider or from a customer.
In this order: put the installation into maintenance mode or take it off the network. Save a snapshot of the compromised state instead of overwriting it — it is the only basis for clarifying the cause. Withdraw access: passwords of all accounts, application passwords, database users, SFTP and SSH keys, plus the salts and keys in the wp-config.php, which ends all sessions. Then compare the core and plugins against the originals and go through the user list and the cron entries. Only after that restore or rebuild, and take over the content rather than the files. If personal data is affected, the 72-hour period under Article 33 GDPR applies.
A cleanup without clarifying the cause is pointless, because the entry route stays open and the same findings reappear within weeks. That is why the question of how somebody got in always belongs to the cleaning: an outdated plugin, a stolen editorial password, a neighbouring project on the same hosting package, an old FTP account. And there is a limitation that we state instead of avoiding: on an installation that has not been maintained for years and whose logs have rotated, the route often can no longer be determined. In that case a clean rebuild with the content taken over is more reliable than a second cleaning run.
No, but it is not worthless either. A web application firewall or a security plugin filters known attack patterns and buys time — especially in the cases where a vulnerability has been published but no patch is available yet. What they do not do: recognise an attack through legitimate, authenticated requests, replace a plugin that no longer has a maintainer, update a PHP version that no longer receives security updates itself, or make a backup restorable. Useful as an addition to maintenance, not as a replacement. Additional plugins are also code themselves, and that code has to be maintained.
Support on third-party hosting is possible and common. The requirements are SSH access, a usable deployment route, a staging environment or the option to set one up, and access to the backups. If that is missing, every maintenance window becomes more expensive than a migration, and we say so before the contract. We run our own servers in Germany on Proxmox clusters; a change is possible but not a condition. We set out the boundary of responsibility between hosting and application in writing beforehand, so that in case of a fault nobody has to start by looking for who is responsible.
On its own requirements page, WordPress recommends PHP 8.3 or newer and MariaDB from 10.11 or MySQL from 8.0 (retrieved 17 August 2026). The technical minimum values are much lower at PHP 7.4 and MySQL 5.5.5, but these are versions at the end of their life cycle that no longer receive security updates — WordPress points this out explicitly on the same page. For day-to-day operation this means two things. The PHP version belongs in the maintenance, not in a separate project. And a step to a newer PHP version is tested on staging, because older plugins break there more reliably than during a core update.
Yes, that is the most common reason for an enquiry. What we need is an administrator account in the back end, SSH or SFTP access, database access and, if there is one, the repository. Before we commit, we look into the code, the plugin inventory and the hosting and give a written assessment; only after that does a contract come about. That is not a formality but a condition — you cannot take responsibility for a state you do not know. In rare cases we decline, for example when there are traces of a compromise or central custom developments without source code. A rebuild is then more honest than a maintenance contract.
No law states an explicit obligation to update WordPress. However, Article 32 paragraph 1 GDPR requires technical and organisational measures according to the state of the art, and a procedure for reviewing them regularly; the accountability under Article 5 paragraph 2 lies with the controller, not with the agency. In practice this means: you do not need a good feeling but a log that shows when what was updated and when a backup was checked. We deliver that as a fixed part of the maintenance. Whether your company is subject to further obligations beyond this is assessed by your legal advisers.
Enquiry
If the answer is „nobody" or „it does that by itself", you are in the right place. We look at the version, the plugin inventory, the PHP status and the backup situation and tell you what has to happen first — before we talk about a contract.