Skip to content
 All notesRSS feed 

WordPress8 min read

My WordPress maintenance checklist, and what changes on IIS

The routine I've set up for a law firm's WordPress site on Windows and IIS: what I check daily, weekly and monthly, how I audit plugins, and which Linux-based steps work differently.

On this page · 9 sections

I maintain a law firm's WordPress site that runs on Windows Server and IIS. This post is the routine I've set up for it and follow from now on: what I check, how often, and which steps from the usual Linux-based guides work differently on IIS. The full 49-task checklist is at the end as a PDF.

Why I check more often now

Four things changed in 2026, and together they moved security work from my weekly list to my daily one.

Patches race attackers. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins. 46% had no fix from the developer when they were made public. For the most heavily exploited ones, the weighted median time to the first exploit attempt was five hours (Patchstack (opens in a new tab)). Patchstack sells protection, so I read this as one vendor's data, but a weekly update round is clearly too slow for security fixes.

The hole can be PHP, not WordPress. On 21 October 2026, PHP fixed two remote code execution flaws known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619) in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (NCSC-NL (opens in a new tab)). CISA added both to its Known Exploited Vulnerabilities catalog on 26 October (CISA (opens in a new tab)). No WordPress or plugin update could fix that.

Versions expire on fixed dates. PHP 8.2 gets security fixes until 31 December 2026 (PHP (opens in a new tab)). MySQL 8.0 reached end of life in April 2026 (Oracle (opens in a new tab)). For new WordPress 7.1 installs, the Hosting Team recommends PHP 8.4 or 8.5 and MySQL 8.4, and says "a version that is end-of-life upstream is never recommended" (Hosting Handbook (opens in a new tab)).

Certificates expire faster. Public TLS certificates issued since 15 March 2026 can last at most 200 days. The limit drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029 (CA/Browser Forum Baseline Requirements, 6.3.2 (opens in a new tab)).

There's one change in the other direction. Since June 2026, WordPress.org holds new plugin releases before auto-updates deliver them, up to 24 hours at first (WordPress News (opens in a new tab)). By September the hold was six hours, it covered dashboard updates too, and an automated review blocked releases it rated high-risk (Make Plugins (opens in a new tab)). That only covers plugins hosted on WordPress.org. My premium plugins update through their vendors, so it doesn't protect them.

So security alerts are part of my daily check, and PHP, the database and the certificate are part of maintenance, not something I leave to the server.

The site, and what's already in place

The site has a custom theme built with Elementor, Elementor Pro and ACF PRO, and about 30 active plugins. Its Site Health report on 6 November 2026 showed:

  • WordPress 7.1.4, PHP 8.4.27 and MySQL 8.4, which matches the Hosting Team's recommendation. 8.4.27 is the PHP release that fixes PHP2Shell.
  • PHP running through FastCGI on IIS (server API cgi-fcgi).
  • Backups with UpdraftPlus, stored off-site. I also use WPvivid sometimes, as an alternative.
  • An activity log of logins and changes, kept by the Stream plugin.
  • Auto-updates switched on plugin by plugin, not for everything at once.

I patch PHP and IIS on this server myself, I have a staging copy, and WP-CLI is installed on the server. Everything else in this post is the routine from now on, not a record of past results.

What I check and how often

What I check and how often
How oftenWhat I check
DailyUptime alerts
DailyThe last backup finished and reached off-site storage
DailyVulnerability alerts for every installed plugin, theme and core version
DailySecurity releases, applied the same day after a fresh backup
DailyThe activity log: failed logins and new admin users
WeeklyOther plugin and theme updates, on staging first, after reading the changelogs
WeeklyContact forms reach the inbox, not spam
WeeklyIIS logs for 5xx errors and probes such as floods of xmlrpc.php or wp-login.php requests
WeeklyCertificate expiry date
WeeklySearch Console security and indexing issues
MonthlyThe plugin audit (below)
MonthlyUsers, roles, two-factor login and application passwords
MonthlyPHP and database versions and patch levels
MonthlyFile permissions, and any PHP files in uploads
MonthlyA backup restored to staging
QuarterlyA full restore drill and a review of the backup setup
YearlyThe PHP and database upgrade plan, and premium licence renewals

Daily is for alerts and security fixes, which take minutes. The slower work (routine updates, audits and restores) goes into the weekly and monthly slots, when there's time to try it on staging.

The monthly plugin audit

About 30 plugins means about 30 other people's codebases running with full access to the site. Once a month I go through the list and decide for each one: keep, update, replace or delete. I start with WP-CLI:

Plugin inventorybash
wp plugin list --fields=name,status,version,update,auto_update,wporg_status,wporg_last_updated

wporg_status shows closed when WordPress.org has closed a plugin, and stays empty for plugins that aren't hosted there, such as premium ones (WP-CLI (opens in a new tab)). Then I flag:

  • Closed plugins, or no release in about a year. A quiet year doesn't prove a plugin is abandoned, but it's my cue to look closer.
  • Inactive plugins. I delete them instead of leaving them deactivated.
  • Premium plugins, here Elementor Pro and ACF PRO. WordPress.org's hold and review don't cover them, so I check that each licence is active and that updates still arrive from the vendor. In 2025, 29% of the valid vulnerability reports Patchstack received were for premium or freemium components, and 76% of the flaws it found in premium components were exploitable in real attacks.
  • Two plugins doing the same job.

What changes on IIS

The maintenance checklists I read before writing this didn't mention the server at all. WordPress's own Hardening guide (opens in a new tab) uses Linux commands (chmod, .htaccess), and the Hosting Team's compatibility page lists Apache, nginx and LiteSpeed servers, not IIS. Here's what each step becomes on IIS:

Linux-based steps and their IIS equivalents
In most guidesOn IIS
Read /var/log/nginx/ or /var/log/apache2/IIS writes W3C logs, by default to %SystemDrive%\inetpub\logs\LogFiles, one file a day.
chmod 755 and 644, 400 or 440 for wp-config.phpNTFS permissions for the site's application pool identity, IIS AppPool\<PoolName>, set with icacls or the Security tab.
Rewrite rules in .htaccessweb.config. WordPress writes its permalink rules there if the file is writable, so it's worth deciding whether the application pool may change it.
.htaccess that stops PHP running in uploadsA web.config in uploads that blocks .php with request filtering (below).
A server cron job for WP-CronWindows Task Scheduler calling wp-cron.php, with DISABLE_WP_CRON set to true.
The package manager updates PHPPHP for IIS is the Non-Thread Safe Windows build. I update it myself.
An ACME client renews the certificateI renew and bind the certificate in IIS Manager, which is why the weekly expiry check matters.
df -hGet-PSDrive C in PowerShell.

Sources for the table: Microsoft Learn on IIS log files (opens in a new tab) and application pool identities (opens in a new tab), WordPress's reference for iis7_save_url_rewrite_rules() (opens in a new tab) and its guide to running WP-Cron from the system scheduler (opens in a new tab), and PHP for Windows (opens in a new tab), which recommends the Non-Thread Safe build for FastCGI on IIS.

This is the web.config I use in wp-content/uploads. I tested it on staging. IIS answers a blocked request with a 404 and logs it as 404.7 (Microsoft (opens in a new tab)).

wp-content/uploads/web.configxml
<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <fileExtensions>
          <add fileExtension=".php" allowed="false" />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

PHP2Shell is why the PHP row matters most to me. The advisories cover every PHP installation that serves web requests, including php-cgi, which is what FastCGI runs on IIS. On this server, keeping PHP patched is my job, so the monthly version check is where I catch it.

What's next

WordPress 7.2 is planned for 8 December 2026, with the first release candidate due on 17 November (Make WordPress Core (opens in a new tab)). I'll test it on staging during the release-candidate phase before the live site gets it.

Download the full checklist

The full checklist has 49 tasks across daily, weekly, monthly, quarterly and yearly cycles, with priorities, reasons, a list of problems that should stop everything else, and log templates: Download the checklist (PDF, 0.7 MB) (opens in a new tab).

The checklist was built from AI-assisted research, which I reviewed and adapted for this site. Its facts were last checked on 7 November 2026. Its commands assume Linux; the IIS table above covers the differences. Versions and dates change, so check php.net and the Hosting Handbook before you rely on them.

FAQ

Does a fully updated WordPress site still need server updates? Yes. PHP2Shell in October 2026 was a flaw in PHP itself, so only a PHP update fixed it. Updating WordPress and plugins didn't help, which is why the PHP version is part of my monthly check.

Is WordPress maintenance on IIS different from Linux? The tasks are the same, but the tools change: NTFS permissions instead of chmod, web.config instead of .htaccess, IIS logs instead of Apache or Nginx logs, and Task Scheduler instead of cron. On IIS you may also be the one who updates PHP.

How often should a WordPress site be maintained? Check security alerts every day and apply security fixes the same day, because the most-exploited plugin flaws see attacks within hours. Routine updates can go weekly after a staging test, and audits, user reviews and backup restores monthly.

AI note: The checklist was built from AI-assisted research, which I reviewed and adapted for this site. This post was also drafted with AI help from my notes and answers; I reviewed and approved it.

Sources