Audit My Site Get Started

Category: By Role

  • Core Web Vitals for WordPress: LCP, INP and CLS

    Core Web Vitals for WordPress: LCP, INP and CLS

    Contents

    1. 01
      Work out which metric is failing

      The short answerHow it actually worksWhy it mattersWhat good looks like

    2. 02
      Fix the one that is actually failingWhat to do about it
    3. 03
      Avoid the traps

      Common misconceptionsWhat this does not solve

    The short answer

    Three metrics make up Core Web Vitals, and each has its own threshold:

    LCP · Loading

    How long the biggest visible element takes to render.

    INP · Interactivity

    How long the browser takes to respond, start to finish, to anything a visitor clicks, taps or types into.

    CLS · Visual stability

    Whether content jumps around while the page is still loading.

    Not Core Web Vitals

    Time to First Byte, First Contentful Paint and Total Blocking Time show up in the same reports and get talked about in the same breath, but none of the three is a Core Web Vital. They are diagnostic metrics that help explain why LCP, INP or CLS is failing. Treat them as supporting evidence, not as a fourth or fifth vital to chase.

    How it actually works

    Largest Contentful Paint

    The LCP element is whichever single thing on the page is biggest by rendered area: usually a hero image, a video poster frame, a CSS background image or a large block of text. Google’s own measurement includes any redirect delay, connection time and server response time before that element can even start rendering, which is why a slow WordPress LCP is usually a hosting and Time to First Byte problem before it is an image-weight problem. Fix the server response first, or the image work does very little.

    A common WordPress misconfiguration works against the reader here directly: lazy-loading the LCP element itself. Lazy-loading defers an image until it is about to enter the viewport, and a hero image is in the viewport from the first paint, so telling it to lazy-load delays the exact element the metric is timing. Preload it instead.

    See the usual reasons a WordPress site loads slowly for the fuller list of causes behind a slow server response.

    Verify

    Confirm which element PageSpeed Insights or Search Console names as the LCP element for the page, then check whether it is set to lazy-load. If it is, that alone can explain a poor score with no other cause present.

    Interaction to Next Paint

    Interaction to Next Paint replaced First Input Delay on 12 March 2024. The two measure different things.

    Before 12 March 2024

    First Input Delay

    Only timed the delay before the browser started processing the very first interaction.

    Current

    Interaction to Next Paint

    Times the full latency, start to finish, of the browser’s response to every interaction on the page, and reports the worst one observed.

    On WordPress, that number is driven almost entirely by the cumulative JavaScript weight of the plugin stack: page builders, sliders, chat widgets, analytics tags and ad scripts all queue work on the same main thread a click has to wait behind.

    Verify

    Check whether a site that passed comfortably under First Input Delay now fails under Interaction to Next Paint with no code change at all. That gap is the clearest sign the two metrics measure different things, not that the site got slower.

    Cumulative Layout Shift

    The scoring formula is impact times distance: how much of the visible screen moved, multiplied by how far it moved. Two small, unrelated shifts add up the same way one big one does.

    On WordPress, the usual causes are missing width and height on images, a web font swap that resizes text after the page has already rendered, and ads, cookie banners or other content injected late into the page.

    Verify

    Reload the page and watch the first two seconds for anything visibly jumping, a button moving as an ad loads in above it, or text reflowing as a font swaps in.

    Why it matters for a WordPress site

    Google Search Central’s own wording on this is worth quoting directly rather than summarizing:

    “Google Search always seeks to show the most relevant content, even if the page experience is sub-par… Having a great page experience can contribute to success in Search, in such cases.”

    “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results.”

    Source: Google Search Central, page experience

    Read plainly, that makes Core Web Vitals a contributing signal among many, not a dominant one. Relevant content that scores poorly on Core Web Vitals can still outrank thin content that scores well.

    What good looks like

    The same three thresholds, restated as the number that gets checked: LCP at 2.5 seconds or less, CLS at 0.1 or less, and INP at 200 milliseconds or less. Google scores each one at the 75th percentile of real visits, segmented separately for mobile and desktop, so a site can pass on desktop and fail on mobile with nothing else different.

    Two different reports can disagree, and it helps to know why before trusting either one on its own.

    Field data

    Chrome User Experience Report

    The data Search Console’s Core Web Vitals report is built on. Reflects real visits from real devices and connections over a rolling window.

    Lab test

    Lighthouse in PageSpeed Insights

    One simulated visit, on one simulated connection, at one moment.

    A site can score well in that single lab run and still fail in the field report, because the field data carries the slow connections and low-end phones the lab test never simulates.

    Server response time also depends on infrastructure the reader is already paying for.

    What to do about it

    A core web vitals fix starts with the diagnosis above, not with a plugin. Each metric has its own fix, and none of the three overlaps much with the others.

    For LCP

    Check Time to First Byte first. Managed WordPress hosting and an edge cache (a Cloudflare-style integration in front of the site) address server response time directly. Once that is solid, move to the hero image itself: serve it in a modern format such as WebP, and preload it rather than lazy-loading it.

    For INP

    Audit the plugin stack for scripts running on every page load that only need to run on one or two. A slider script loading on a page with no slider, or a chat widget loading before anyone has scrolled near it, are common candidates.

    For CLS

    Set an explicit width and height on every image and embed, and reserve space in the layout for anything that loads in late, ads and cookie banners included.

    See the full speed checklist, one item at a time for the complete list beyond these three, and have someone check which metric is actually failing before spending time on a fix that targets the wrong one.

    See how this is held on the retainer.

    NoDrama’s speed optimization work checks Core Web Vitals against the site on an ongoing basis, not as a one-time fix.

    See Speed Work

    Common misconceptions

    “A caching plugin fixes Core Web Vitals.”

    It improves Time to First Byte and repeat-visit LCP. It does nothing for INP, which is client-side JavaScript running after the page has already loaded, and nothing for CLS, which is a markup and layout problem.

    “The padlock and a CDN mean performance is handled.”

    A CDN helps LCP through Time to First Byte and faster asset delivery. It has no effect on the JavaScript execution behind INP or the missing dimensions behind CLS.

    “Core Web Vitals is a major ranking factor.”

    Google’s own wording, quoted above, treats it as a contributing signal that can help when content is otherwise comparably relevant, not a dominant one that overrides relevance.

    What this does not solve

    Core Web Vitals measure loading, interactivity and visual stability. They say nothing about uptime, security or content quality, and a site can pass all three metrics while having an outdated plugin or no backup in place.

    Conclusion

    Core Web Vitals are three separate metrics with three separate causes: LCP traces to hosting and image handling, INP traces to plugin JavaScript, CLS traces to unreserved layout space. Check Search Console to see which one is actually failing before changing anything, because a fix aimed at the wrong metric leaves the score exactly where it started.

  • How Do You Check If Your Website Is Secure?

    How Do You Check If Your Website Is Secure?

    Contents

    1. 01
      Understand what each check actually tells you

      The short answerHow it actually works

    2. 02
      Run the checks

      What good looks likeWhat to do about it

    3. 03
      Know what still isn’t covered

      Common misconceptionsWhat this does not solve

    The short answer

    Checking whether a website is secure means running four separate signals, not one. Each covers a different layer, and a clean result on any one of them is not a clean bill of health for the other three.

    Signal What it checks What it misses
    Google Safe Browsing status
    		Whether Google’s crawler classified the URL as malware, phishing, unwanted software or deceptive content on a recent pass Anything injected since that pass, or anything on a page the crawler never reached
    Blacklist (DNSBL) check
    		Whether the domain or IP has been reported to a third-party list such as Spamhaus or Barracuda A fresh compromise nobody has reported yet
    Certificate validity (the padlock)
    		That the connection is encrypted and that whoever requested the certificate controlled the server at issuance Patched software, server-side validation, or malware already on the site
    File-level malware and vulnerability scan
    		The actual files and database for injected code, plus installed versions against known disclosures Nothing, but it is the one check none of the URL-only tools can run
    The four checks that make up a website security check, and what each one covers.

    How it actually works

    Google Safe Browsing

    Google’s Safe Browsing technology scans its own web index daily. As Google puts it, “Our Safe Browsing technology scans our web index on a daily basis to identify unsafe websites.” A URL that turns up gets classified as malware, phishing, unwanted software or deceptive content. Malware detection works by scanning sections of the index and testing pages in a virtual machine to see if it gets infected. Phishing detection runs on statistical models instead.

    Once a site is flagged, the warning is added within minutes of detection, and it takes about half an hour on average to show up externally. That speed cuts both ways.

    Catches

    A site that was actively serving bad content at its last crawl.

    Misses

    Anything injected after that crawl, anything on a page the crawler never reached (behind a login, or blocked by robots.txt), and a vulnerable plugin sitting on the site that nobody has exploited yet.

    Run the lookup directly at Google’s Safe Browsing site-status tool, and read how the scan actually works in Google’s Safe Browsing transparency FAQ. For the fuller process this single check feeds into, see the fuller checklist this feeds into.

    Blacklist and DNSBL checks

    A blacklist check is a DNS lookup, cross-referenced against third-party lists such as Spamhaus, Barracuda or SORBS. Each list sets its own listing criteria. A clean result here means the domain or IP has not been reported yet, not that the underlying code is clean. It also misses a site that was compromised recently and hasn’t been reported, and it can produce a false positive on shared hosting, where one bad neighbor gets an entire IP block listed.

    The padlock and certificate

    A valid certificate confirms two things only: the connection between browser and server is encrypted, and whoever requested the certificate had administrative access to the server at the moment it was issued. It does not confirm the software behind that connection is patched, that server-side validation is sound, or that the site is free of malware.

    Free certificate issuance changed what the padlock actually signals. A phishing site can get the same valid HTTPS certificate a legitimate business gets, and vendor reporting on phishing incidents has noted that most reported phishing sites now carry a valid certificate too.

    Read the padlock correctly

    Treat the padlock as confirmation of encryption, never as confirmation of safety.

    Malware and vulnerability scanning

    This is the layer the first three checks cannot touch, because it requires looking at the site’s own files rather than at how the outside world sees the domain. A malware scan inspects the files and database for injected code, unexpected admin accounts and altered core files. A vulnerability check compares the installed versions of core, themes and plugins against public disclosure databases such as WPScan’s.

    Both require server-side access or a direct look at the codebase. A URL-only checker run from outside the site cannot do either.

    Where the free checks stop

    External reputation
    • Safe Browsing
    • Blacklist
    • Certificate

    Requires file-system access

    Requires file-system access

    On the server
    • Malware scan
    • Vulnerability check

    A diagram showing the boundary between external reputation checks and a file-level security scan.

    External reputation and file-level access are two different zones. Safe Browsing, blacklist status and the certificate all judge the site from outside. A malware scan and a vulnerability check are the only ones that look at what is actually sitting on the server.

    What good looks like

    A genuinely clean result means all four signals come back clear at once:

    No Safe Browsing flag
    No blacklist listing
    A valid certificate with no mixed-content warnings
    A file-level scan that turns up no injected code and no versions matching a known disclosure

    One green result out of four is a start, not a finish. It tells you one layer looks fine today. It says nothing about the other three.

    What to do about it

    1. 01

      Run the Google Safe Browsing site-status lookup directly against the domain.

    2. 02

      Run a blacklist (DNSBL) checker against the domain to see if it appears on Spamhaus, Barracuda or a similar list.

    3. 03

      Check the certificate’s validity in the browser, and look in the browser console for mixed-content warnings on pages that should be fully encrypted.

    4. 04

      Run a malware and vulnerability scan, either through a security plugin with file-system access or through a fuller audit.

    Each of these is a snapshot, not a standing guarantee, so the useful habit is running all four again after any change to the site, not just once after a scare.

    Get the layer those four checks can’t see.

    NoDrama’s free website audit checks the site’s actual files and versions, no pitch attached.

    Audit My Site

    Common misconceptions

    “HTTPS means the site is safe.”

    It confirms encryption in transit and that someone controlled the server when the certificate was issued. That’s all it confirms.

    “A clean Safe Browsing result means nothing is wrong.”

    It reflects only what Google’s crawler has seen so far, and that can lag behind a fresh infection by hours or days.

    “A security plugin covers all of this.”

    A plugin scans what it has file-system access to. Reputation flags such as Safe Browsing and blacklist status are external judgments, and a local plugin cannot see or clear them.

    What this does not solve

    None of the four checks above replace an ongoing, operated security practice: updates tested before they go live, monitoring that runs continuously rather than once, and a documented process someone actually follows. A clean result across all four today answers only “as of today.” For how the security work is scoped, see how the security work is scoped, and for who actually watches this after today, see who actually watches this after today.

    Conclusion

    Checking whether a website is secure is four separate signals, not one: Google Safe Browsing status, blacklist status, certificate validity, and a file-level malware and vulnerability scan. Each one is narrow, each one misses what the other three catch, and the only honest answer to “is my site secure” comes from running all four rather than trusting whichever one came back clean first.

  • How Do I Know If My WordPress Site Is Hacked?

    How Do I Know If My WordPress Site Is Hacked?

    Contents

    1. 01
      Work out what you’re looking atWhat a hacked site looks like
    2. 02
      Check the five signs

      The five signsHack vs. broken

    3. 03
      Act, and stop it recurring

      What to do once you’re sureTroubleshootingStop it happening againWhat this doesn’t solveIs your site hacked?

    What does a hacked WordPress site look like?

    Google’s own definition: “This is any content placed on your site without your permission because of security vulnerabilities in your site.” Three common ways in: a vulnerable plugin, weak credentials, or an outdated core file with write access.

    The usual motive is SEO spam or redirects, via cloaking: the real site loads for a logged-in admin, and a different, injected page loads for Googlebot or a search visitor. “It looks fine to me” is not a clean bill of health, since that’s exactly what this hack is built to show.

    See whether WordPress itself is the weak point for that separate question.

    How to confirm the site is compromised (the five signs of a compromised website)

    Five signs checklistAny one of these holding is enough to act on
    1. 01 Google or browser warning
    2. 02 Pages you never published in search
    3. 03 Redirects to another site
    4. 04 Unknown admin users or files
    5. 05 Host suspension or abuse notice
    Five signs a WordPress site has been hacked, shown as a checklist.

    Each sign has its own cause and check; none needs developer skill.

    1. Google or your browser warns people away

    Google’s Search Console help: “Pages or sites affected by a security issue can appear with a warning label in search results or an interstitial warning page in the browser when a user tries to visit them.” This shows as “This site may be hacked” in search, or a warning in Chrome, under Hacked Content, Malware and Unwanted Software, or Social Engineering.

    Verify it

    Open Security Issues in Search Console (site must be verified there). Green “no issues” clears this; anything listed does not. See Google’s Security Issues help.

    Google’s Security Issues help

    2. Search results show pages you never published

    Injected spam: pharmacy, gambling or foreign-language pages, often served only to Googlebot.

    Verify it

    Search site:yourdomain.com in a logged-out incognito window and scan titles and snippets for anything that matches nothing in your CMS.

    3. Visitors get sent to another site

    Injected JavaScript, or a modified .htaccess or functions.php file, often triggers only on referrer or device, so a direct visit looks fine. Wordfence documented a 2019 campaign exploiting vulnerable plugins to inject this code.

    Verify it

    Visit the site logged out, in incognito, arriving from search rather than typed, and once more from a phone on a different network.

    Wordfence’s 2019 write-up

    4. Admin users or files appear that nobody created

    This sign is the foothold: a new admin account, an extra file in wp-content or plugins, or an edited core file lets an attacker return after cleanup. wordpress.org’s checklist includes unauthorised new users.

    Verify it

    Open Users, filter by Administrator, and match every account to a named person. Ask a developer to check file-modification dates in wp-content and core.

    wordpress.org’s FAQ on a hacked site

    5. Your host suspends the site or reports abuse

    Hosts run their own malware and abuse scanners, independent of Google. A suspension, or a report the site is sending spam or attacking others, can arrive before, or without, a Google flag.

    Verify it

    Check host email and the control panel for a suspension notice or an abuse report.

    When it looks like a hack but isn’t

    A broken plugin update, an expired SSL certificate, a stale cached page, or a host outage can look alarming and match none of the five signs above. If Security Issues is clean, admin accounts belong to the team, and the host hasn’t flagged anything, the read is broken, not hacked: roll back, renew, or contact the host. An SSL warning or outage doesn’t need a forensic audit.

    What you see Points to a hack Points to broken
    Search Console Security Issues An issue is listed Green “no issues”
    Unknown admin users An account nobody can name Every account belongs to the team
    Host abuse notice Suspension or abuse report received Host hasn’t flagged anything
    SSL warning only — Expired certificate: renew it
    Error after an update — Broken plugin update: roll back
    Stale cached page — Cache serving an old version
    Table comparing signs of a compromised website with ordinary WordPress failures.

    See how tested updates and rollback are handled.

    What to do once you’re sure

    wordpress.org’s first steps: stay calm, document what you found, and scan.

    Option 1Recommended

    Easiest: tell your host and follow wordpress.org’s first steps

    Your host runs its own scanners and may already know. Follow wordpress.org’s guidance from there.

    Option 2

    Done for you: hand it to whoever runs security for the site

    A retainer with monitoring and backups already running means some of these signs can be caught before you notice them.

    Option 3

    Manual: restore from a clean backup and close the foothold

    Restore to a known-clean point before the first sign appeared: the older the sign, the further back. Remove admin accounts nobody can name, and have a developer compare files against a clean copy. See how off-site backups and restores work.

    Verify it

    Re-run all five checks: Security Issues clean, site: search clean, incognito visit from search and mobile clean, Users list matches named people, no host notice.

    Troubleshooting

    “Google says this site may be hacked, but Search Console shows no security problems”

    Cloaking can explain the mismatch: the spam goes to Googlebot and search visitors, not you. Run the site: search and incognito check rather than trusting either alone.

    “My security plugin says everything is clean”

    A scanner reports what it was configured to catch; silence isn’t proof of more. Cross-check against the signs above.

    How to stop it happening again

    Turn the causes above into a routine: tested updates, admin accounts reviewed, monitoring and scanning running, and off-site backups you could restore from tomorrow. The monthly check is the five-sign list. See the site’s state now with NoDrama’s free WordPress audit.

    See what a security retainer covers.

    NoDrama’s WordPress security retainer runs security monitoring and malware scanning on every plan, which can catch some of these signs before you do, and keeps off-site backups to restore from if one turns up.

    See Security Work

    What this guide does not solve

    It doesn’t cover a full malware cleanup, a forensic investigation, or how a specific attacker got in. A site handling payments or client data also has obligations this guide doesn’t cover.

    So, is your WordPress site hacked?

    Five signs settle it: a Google or browser warning, unpublished pages in search, a redirect elsewhere, an unrecognised admin account or file, or a host suspension. None depend on how the dashboard looks while logged in; the checks happen outside it. If none hold, the read is broken, not hacked, or fine.

  • WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    In this piece

    1. 01Work out what you are actually running
    2. 02Apply updates the safe way
    3. 03Confirm it held

    The three layers you are updating

    Core is WordPress itself, the software that runs everything else. Themes control how the site looks. Plugins add functions core does not have. All three ship updates on their own schedules, and none of them wait for the other two.

    Three layers, two kinds of updateCore can run on autopilot. Theme and plugin updates need a test step first.
    Core

    WordPress itself. Scheduled major releases, minor releases as needed.

    CompatibilityStrict backward compatibility across minor versions
    Auto-update defaultOn, for minor and major releases on WordPress 5.6 or later
    Safe to automate

    Theme

    Controls how the site looks. Ships on the theme author’s own schedule.

    Plugin

    Adds functions core does not have. Ships on each plugin author’s own schedule.

    CompatibilityIndependently coded, no compatibility guarantee with your other plugins, theme or PHP version
    Auto-update defaultOff. Opt-in per item or in bulk since WordPress 5.5
    Test before it goes live

    A mechanism diagram, not a risk score. Testing and rollback on the plugin and theme layer are offered by several providers.

    Diagram comparing WordPress core, theme and plugin update risk.

    Core minor releases are near-automatic and safe, because WordPress core maintains strict backward compatibility across minor versions. That is the whole reason they can run unattended. Plugin and theme updates are a different animal. Each one is written independently, by a different developer, with no obligation to stay compatible with any other plugin, theme or PHP version on your site. WordPress has no way to test that combination in advance, which is exactly why the project leaves plugin and theme auto-update off by default. You have to turn it on per item, or in bulk, since WordPress 5.5.

    That default is worth sitting with. The people who built the update system decided the compatibility risk on this layer was high enough that it should not happen without someone choosing it. “Turn on auto-update for everything” is advice that skips the one step, testing, that actually prevents breakage. It is not wrong that updates should happen. It is wrong about which layer is safe to leave unattended.

    This is the gap a maintenance retainer that separates the safe updates from the risky ones is built to close.

    Check what you have now

    Before changing anything, confirm what is actually running. In wp-admin, the Dashboard > Updates screen shows the current core version and lists any plugin or theme with an update pending. The Plugins screen shows every active plugin and its version number. Appearance > Themes shows the active theme and any child theme in use.

    Write the list down, or export it, before you touch a single update. You cannot tell whether an update changed something if you did not know the state it changed from.

    Verification step

    Confirm the list matches what is actually active in wp-admin, not what you remember installing. Plugins get deactivated and reactivated, themes get swapped, and a list based on memory is often out of date.

    How to handle core updates

    Core minor releases (as-needed maintenance and security fixes, no new features) are safe to leave on auto-update. WordPress ships three major releases a year, roughly four months apart, and on installs running WordPress 5.6 or later, both minor and major releases auto-apply by default. Major releases change more surface area than minor ones, so they carry more risk even though the default treats them the same as minor releases on newer installs. For more detail, see how often WordPress actually ships updates.

    Via plugin

    An update-management plugin can group and schedule core updates, giving you a single place to see what applied and when, rather than checking the Updates screen manually.

    Via server

    WP-CLI or a hosting panel’s built-in update trigger can apply core updates from the command line or a dashboard, which is the more common route on managed hosting.

    How to handle plugin and theme updates

    WordPress does not auto-update plugins and themes by default, and that default is the clearest signal available that this layer needs more than a toggle. The general mechanism for testing an update before it reaches visitors works the same way regardless of who runs it: pull the update into an environment that mirrors the live site, same PHP version, same active plugin and theme stack, same content, apply it there first, and confirm the site still renders and functions before applying it live. Take a backup immediately before the live update goes out, so the change is reversible if something surfaces after it ships.

    Tested-update workflowThe path an update takes before it reaches the live site
    1. 01
      Update pulled into a staging environment mirroring liveSame PHP version, plugin and theme stack, and content.
    2. 02
      Applied in staging
    3. 03
      Checked for rendering and function
    4. 04
      Applied live, with a backup taken immediately before
    Flow diagram showing a WordPress update tested in staging before going live.

    What NoDrama’s own care plans confirm on this layer, and no more: plugin and theme updates run with key pages photographed before and after, and are put back if something breaks, on all three plans. This is not unique to NoDrama. ManageWP, WP Umbrella and WP Remote all offer comparable tested-update mechanisms.

    This is where how NoDrama checks updates matters, because building a test step yourself means standing up and maintaining a second environment.

    Via plugin

    A staging or cloning plugin is the DIY route: it clones the live site into a separate environment where updates can be applied and checked before going live.

    Via server

    Some hosts include a staging environment as part of the hosting plan, which removes the need for a separate plugin.

    Via code

    A developer-run site can manage this with a manual git and WP-CLI workflow, pulling updates into a version-controlled staging branch before deploying to production.

    Via host or CDN

    Some managed hosts and CDN providers offer their own staging or rollback tooling as part of the platform, where it is included.

    Apply the change

    As general good practice, not a documented NoDrama process: apply core minor updates first, since they carry the least risk. Then work through plugin and theme updates via the tested path above, one at a time or in a controlled batch, never all of them at once with no backup in place. No internal NoDrama documentation confirms this specific sequencing. It is standard practice, presented here as such.

    A full pre-update checklist covers the steps in more detail if you are building this process yourself.

    Verify safely

    Load the updated site logged out, in a private or incognito window, not just in wp-admin. Check the pages that matter most: the homepage, any checkout or lead form, and any page that uses the functionality the updated plugin touches. Confirm the backup taken before the update is still current and restorable, not just that it exists.

    Verification step

    Confirm the site functions for a logged-out visitor. A page that loads fine for a logged-in admin can still be broken for everyone else, since caching, session state and admin-only scripts can mask a problem that a normal visitor would hit immediately.

    See how updates are checked and put back.

    NoDrama’s WordPress maintenance service photographs your key pages before and after every plugin and theme update, and puts back anything that breaks.

    See Maintenance Work

    Troubleshoot

    “The update broke the layout”

    This is usually a theme or plugin CSS or JavaScript conflict introduced by the new version. Roll back to the pre-update backup, then test the update again in staging before reapplying it live.

    “A plugin update will not apply, or the site white-screens”

    This is usually a PHP version mismatch. Check the plugin’s stated minimum PHP version against the version your host actually runs, since an update can require a newer PHP version than the site is on.

    What this does not solve

    A tested-update process catches problems before they reach visitors. It does not make every plugin update backward compatible by itself, and it does not eliminate the underlying risk that plugin code can change without warning. Testing reduces the cost of that risk. It does not remove the risk itself.

    Conclusion

    The practical version of this is simple to state, even if it takes some process to run. Core minor releases can be left on autopilot, because WordPress guarantees their backward compatibility. Plugin and theme updates cannot, because WordPress itself treats them as opt-in, and they need to be tested before they go live rather than applied and hoped for. A maintenance retainer that separates the safe updates from the risky ones is the practical way to get updates checked without building a staging process yourself.

  • Cyber Essentials Security Update Management: Does the 14-Day Rule Cover Your WordPress Site

    Cyber Essentials Security Update Management: Does the 14-Day Rule Cover Your WordPress Site

    Contents

    1. 01Work out whether this control reaches your site
    2. 02Meet the requirement
    3. 03Confirm it holds at renewal

    Does the 14-day rule cover your website

    Cyber Essentials: Requirements for IT Infrastructure v3.2 lists the software categories that fall under security update management as “operating systems, commercial off-the-shelf applications, extensions, interpreters, scripts, libraries, network software and firewall and router firmware.” Read plainly, WordPress core, an active theme and the plugins running on it are instances of that category. They are commercial or freely distributed off-the-shelf applications and extensions, installed on a server the way any other software is installed on a device.

    That reading is a reading, not a ruling. IASME’s scope guidance places web applications inside the organisational services a supplier’s controls have to cover, which supports treating the site as in-scope software. But whether a specific install counts is the assessor’s call, the same answer this objection gets whenever it comes up: don’t argue the point, quote the scope line, and say plainly that a given install falls inside the assessor’s judgment rather than a fixed rule.

    There is a real question about whether a bespoke, custom-built component sits differently under the requirement. The exact exclusion wording for bespoke software could not be verified against a primary source in the research behind this piece, so it is not quoted or restated here. Treat it as an open question to raise with your assessor, not an assumption to build a patching schedule on.

    For a supplier who already runs a maintenance retainer built around this control, NoDrama’s WordPress maintenance retainer is one way that reading gets addressed in practice: it treats WordPress core, the theme and plugins as software that needs the same dated update discipline as the rest of the estate.

    What counts as “critical or high risk”

    The 14-day clock is not a general instruction to update software when convenient. NCSC’s requirement defines the trigger precisely: a “critical” or “high risk” vulnerability is one with a CVSS v3 base score of 7 or above, or one the vendor itself labels critical or high risk. Either test is sufficient on its own.

    That means the clock is scoped to one severity tier, not every routine plugin release. A minor version bump that adds a feature or fixes a cosmetic bug carries no 14-day obligation. A release that patches a vulnerability the vendor rates critical or high risk does, and the 14 days start running from the date the vendor releases that fix, not from the date someone on your team happens to notice it.

    Update triage and evidenceFrom a vendor release to a record an assessor can check
    1. 01
      Vendor releases updateCore, theme or plugin author publishes a new version.
    2. 02
      Check vendor advisory for severity label or CVSS v3 scoreThe advisory or changelog entry, not a general impression.
    3. 03
      If critical or high risk (score 7+), 14-day clock startsCounted from the vendor’s release date. Routine releases carry no clock.
    4. 04
      Tested, dated update recordWhat was updated, when, and whether it held.
    Diagram of the Cyber Essentials update triage and evidence process.
    Verification step

    Before assuming the clock has started on any given release, check the vendor’s own advisory or changelog entry for the severity label. That label, not a general sense that “it looked important,” is what starts and stops the 14-day window.

    How the update evidence has to work

    Cyber Essentials assessment is evidence-based, not intention-based. What an assessor asks for is a dated record of what was updated and when, not a description of intentions or a general assurance that things get kept current.

    That distinction matters because the two common answers to “is the website patched” fall short in different ways:

    Auto-update toggled on

    Shows a setting, not a result. It does not show whether an update actually installed, when, or whether it broke something and rolled back silently.

    A developer’s verbal confirmation

    Not a standing, checkable record an assessor can review months later.

    A dated, checkable log, by contrast, is exactly the artefact the requirement is written around. If you have not looked at what is currently installed and running, NoDrama’s free website audit is a way to see the current state of plugins and themes before building a patching record around them.

    Verification step

    Confirm any update record shows an install date for the update itself, not just that the auto-update setting is switched on. A toggle is a configuration. A dated entry is evidence.

    What a tested update process looks like

    The general mechanism behind a defensible update process has three parts: pull the update into a staging environment that mirrors the live site, test it there, then apply it to the live site with a backup taken first. That sequence is what turns “we updated it” into “we updated it, checked it worked, and could have reversed it if it hadn’t.”

    Plugin and theme updates are one of the features every NoDrama plan includes. NoDrama’s WordPress maintenance retainer describes how that update handling works in practice.

    Restore testing is the artefact closest to the dated evidence the requirement asks for: a scheduled, dated confirmation that a backup actually restores, rather than a promise that backups exist. The three plans differ in backup frequency, response commitment, job capacity and restore-testing cadence, not in whether malware scanning, firewall protection or plugin and theme updates are included, since those are universal across every tier:

    Plan Backup frequency Response commitment Job capacity Restore testing
    The Standard
    $129/month    		 Daily automated 4 hours One small job at a time Annual
    The Higher Standard
    $249/month    		 Automated, every 12 hours 2 hours Two small jobs at a time Twice-yearly
    The Highest Standard
    $479/month    		 Real-time, on every change 1 hour Three small jobs at a time Quarterly

    All three plans also include offsite backups with 90-day retention, uptime monitoring, a global CDN, and a staging environment, alongside malware scanning, firewall protection and plugin/theme updates.

    Table comparing NoDrama’s Standard, Higher Standard and Highest Standard plan backup frequency, response commitment, job capacity and restore-testing cadence.

    NoDrama’s pricing page sets out the three plans and what each covers.

    What an assessor actually checks

    At self-assessment or during a Cyber Essentials Plus scan, an assessor checks whether a critical or high-risk fix is still open past 14 days from the vendor’s release date. That is the specific thing being tested, not a general impression of how well-maintained the site looks.

    Passing the assessment is the priority a dated record serves. A verbal assurance that “we keep it updated” does not stand up to that check the way a log with install dates does. NoDrama’s pricing page shows the response commitment at each plan, which matters here because a faster response time shortens the gap between an advisory landing and a fix being applied.

    See how the maintenance retainer covers this control.

    NoDrama’s WordPress maintenance retainer covers plugin and theme updates on every plan.

    See Maintenance Work

    What this does not solve

    A maintenance retainer supports the security update management control. It does not itself decide whether a given install is in scope, and that decision stays with the assessor in every case. It is not a guarantee that every advisory gets met inside 14 days either; a tested update process shortens the gap between a critical or high-risk advisory and a dated fix, but no plan promises a fixed outcome on every release.

    It also does not resolve the bespoke-component scope question. Where a component was custom-built rather than off-the-shelf, whether it falls under the same 14-day clock stays a question for the assessor, and this piece does not assert an answer to it.

    Conclusion

    WordPress core, a theme and a stack of plugins read as commercial off-the-shelf software under Cyber Essentials, which puts them inside the same software scope as the laptops and servers the requirement was written for, though the specific call on any one install belongs to the assessor. The 14-day clock only applies to updates the vendor rates critical or high risk, measured by a CVSS v3 base score of 7 or above, and it runs from the vendor’s release date. What clears that check at assessment is a dated, checkable record of what was updated and when, not an auto-update toggle or a verbal assurance, and a tested update process is what produces that record.

  • Do Websites Really Need Monthly Maintenance?

    Do Websites Really Need Monthly Maintenance?

    Start here

    1. 01Understand why this keeps coming up
    2. 02Work out where your site sits
    3. 03Decide what to do about it

    Why a launched site does not stay finished

    WordPress core, the theme and every plugin on a site are written and versioned independently. Each one ships on its own schedule, set by its own author, with no coordination between them.

    Core itself changed pace recently. As WordPress explained in A new cadence for WordPress core: “Starting in 2025, WordPress will move to a single major release per year, with WordPress 6.8 ‘Cecil’ marking the final major release for the calendar year.” The stated reason is “the energy and resources being diverted due to ongoing legal matters,” and the post frames the change as reversible: “If those lawsuits are dropped or resolved, we’ll revisit this cadence and strongly consider returning to a three-releases-per-year schedule.” Before this, the core release cycle handbook targeted roughly one major release every four months, alongside security and maintenance point releases as needed.

    Plugins and themes follow no such pattern. Some ship weekly. Others go years without a touch. When a vulnerability is disclosed in any one component, the patch that fixes it applies to that component alone. A fix sitting on the plugin author’s server does nothing for a site running the version from before the fix existed, because nobody there applied it.

    What actually breaks a site without upkeep

    Two failure modes account for most of what goes wrong on a site nobody maintains.

    The first is an unpatched security hole: a vulnerability gets disclosed, a patch exists, and the site never receives it. The second is a compatibility break: one component updates, another doesn’t, and the two stop working together. Neither requires an attacker with unusual skill or a site with unusual traffic. Both just require time passing with nobody checking.

    Where the vulnerabilities actually concentrate, from Patchstack’s tracking of the first six months of 2025:

    Component Count Share
    Plugins 3,044 89%
    Themes 386 11%
    Core 1 —

    Source: Patchstack, first six months of 2025. Vendor-tracked figure, not an independent industry consensus.

    A table showing that plugins accounted for 89 percent of new WordPress vulnerabilities disclosed in a six-month 2025 period, compared to 11 percent for themes and effectively none for core.

    Across the ecosystem, 6,700 new vulnerabilities were identified in that period, and 57.6% required no authentication to exploit.

    Patchstack is a commercial vulnerability-disclosure vendor, not a neutral industry body, and there is no independent figure to cross-check these numbers against. Read them as what one vendor’s tracking shows, not as an industry consensus. Even with that caveat, the shape of the finding matches the mechanism above: plugins carry almost all of the disclosed risk, because there are far more of them, written by far more separate authors, patched on far more separate schedules than core ever has to coordinate.

    Does a small brochure site really need this

    Not every site carries the same exposure. A low-traffic site with minimal plugins, no forms handling sensitive data and no e-commerce carries meaningfully lower risk than one running a checkout or a client portal. For that specific case, manual, infrequent, self-managed updates can be an adequate, honest answer.

    The maintenance-needed testTwo variables, and the direction each one pushes
    Many componentsFew components
    Many plugins, no sensitive dataMore moving pieces, each on its own release schedule
    Strongest case for ongoing maintenanceMany plugins, and they touch money, personal data or file uploads
    The narrow honest exceptionFew plugins, nothing touching money or personal data
    Few plugins, handles sensitive dataFewer pieces, but what they touch raises the stakes

    No money, data or uploadsHandles money, data or uploads

    A reasoning aid, not a scored model. The two variables and the direction each pushes, with no weighting between them.

    A simple diagram showing how the number of active plugins and whether a site handles money or personal data together determine how strong the case for ongoing maintenance is.

    The practical test is to count the active pieces of software: WordPress core, the theme, and each plugin. Then ask whether any of them touch money, personal data or file uploads. More components and more of that kind of data both push the case for ongoing maintenance further from optional.

    What a security plugin or auto-updates alone still miss

    A security plugin can scan for known threats and, in some cases, keep itself current. It does not update the other plugins running on the site, and it does not create an off-site backup unless someone configures that separately.

    Turning on automatic updates for everything closes the patching gap, but not the compatibility gap. WordPress can apply some updates in the background, but plugins and themes generally are not auto-updated by default, and even where an update applies cleanly, it can still break a specific plugin and theme combination on your site. An unattended auto-update with no rollback path is itself a known way sites go down, which is a large part of why staging and a tested rollback exist as a step rather than a single button. See how NoDrama tests an update before it goes live.

    What monthly maintenance actually has to cover

    Three things, and none of them substitute for the others.

    Backups

    A real backup covers the database and the file system together, on a schedule tight enough that the restore point is actually usable, stored off the live server. A copy that lives on the same server as the site it protects is not a backup for the case where that server is the problem.

    Confirm it

    Check that your backup destination is off-site, not a folder on the same host.

    Update testing

    Update testing happens on a staging copy before anything reaches the live site, with a rollback path ready if the update still breaks something once it is live.

    Confirm it

    After an update, check the specific pages and forms that depend on the updated plugin, not just that the site loads.

    Monitoring

    Monitoring detects an outage: a site that stopped responding. It does not detect a slow, still-running compromise, and it is not a substitute for patching. It is a detection layer sitting alongside the other two, not a replacement for either.

    What this guide does not solve

    This guide does not tell you whether your specific site has already been compromised. That takes a scan of the actual site, not an article about sites in general.

    It also does not hand you a fixed WordPress-specific number for how often maintenance has to run. The honest answer is “as often as the software underneath keeps shipping updates,” which is continuous rather than a fixed monthly figure, even though most care plans, NoDrama’s included, bill on a monthly cycle.

    NoDrama’s care plans cover backups, tested updates and monitoring at three levels of depth.

    See The Three Plans

    Conclusion

    For most sites running more than a handful of plugins, or handling payments, personal data or file uploads, the answer is yes: ongoing maintenance is not optional, because core, the theme and every plugin keep shipping updates on their own schedules whether or not anyone applies them, and plugins in particular carry the overwhelming share of the disclosed vulnerabilities in the ecosystem. The honest exception is narrow. A near-static brochure site with almost no plugins and nothing touching money or personal data can get by on manual, infrequent, self-managed updates. Everything past that point is a question of how many moving pieces are running and what they touch, not whether WordPress as a platform is somehow dangerous on its own.

  • How to Choose a WordPress Maintenance Company

    How to Choose a WordPress Maintenance Company

    Start here

    1. 01Working out what actually matters
    2. 02Checking a specific vendor against it
    3. 03Avoiding the traps

    The five things that actually separate one WordPress maintenance company from another

    Every established WordPress maintenance company claims tested updates, backups and security monitoring somewhere on its page, so a features list does not tell you much. What actually separates one provider from another is whether five specific things are checkable, not promised.

    Five criteriaWhat to hold any provider to

    Tested updates, with a real rollback pathStaging catches the obvious breakage. Rollback is the separate fallback for what it missed.

    Restore-tested backups, not just takenA backup that has never been restored is a file, not a plan.

    A written response time for a real incident“We’re quick” is not a number. A stated response time is.

    Who keeps the domain, hosting and admin credentialsThis decides how hard it is to leave later.

    The monthly report: evidence, or a marketing emailOne shows what was checked and when. The other reads well and proves nothing.

    Checklist of five criteria for choosing a WordPress maintenance company: tested updates, backups, response time, access ownership, report quality.

    For the fuller list of questions to work through with a specific vendor, see the fuller scope of what a maintenance retainer covers.

    How the core mechanisms actually work, and what each one does not catch

    Knowing the mechanism behind each claim is what lets you ask a useful question instead of an easy one to dodge.

    Mechanism What it catches What it misses
    Update testing Obvious conflicts, caught on a copy of the site before a visitor sees them Breakage that only appears under live traffic, live form submissions or a live checkout
    Backups The database and the files, stored off the production server Whether a recovery actually works, unless someone restore-tests it
    CDN Static assets served from a server closer to the visitor A slow database query or a bloated plugin stack causing the slowness
    Uptime monitoring An outage, an error code or an SSL failure A page that returns a normal response while its checkout or form quietly fails
    Security monitoring Ongoing scanning for vulnerabilities and malware, plus a watch on login activity Anything after onboarding, where the claim is really a one-time scan
    Table comparing WordPress maintenance components, what each one catches and what it misses.

    Tested updates and rollback

    Staging runs the update on a copy of the site first, so obvious conflicts get caught before a visitor sees them. Rollback exists for the failure staging missed, since a staging environment does not carry live traffic, live form submissions or a live checkout, and some breakage only shows up under those conditions. The two are different safety nets, not the same claim said twice.

    Visual regression testing

    This is a pixel-level before-and-after comparison that flags a CSS conflict or a layout shift an update introduced. NoDrama offers a version of it, and so do ManageWP, WP Umbrella and WP Remote. It is worth asking about, but it is not a reason to choose one provider over another on its own.

    Backups

    A real backup covers the database and the files, stored off the production server so a server failure cannot take out both the site and its own backup. The part providers skip is restore testing, actually running a recovery and confirming the result works, which is a different exercise from confirming a backup job completed.

    CDN

    A content delivery network caches and serves static assets from servers closer to the visitor. It does not fix a slow database query or a bloated plugin stack causing the slowness in the first place, and it is typically measured and sold in bandwidth per month.

    Uptime monitoring

    External checks ping the site at intervals and flag an outage, an error code or an SSL failure. What they do not catch is a page that returns a normal response while the checkout or a form on it quietly fails, since the check only confirms the page loaded, not that it worked.

    Security monitoring

    Active monitoring is ongoing scanning for vulnerabilities and malware, plus a watch on login activity. A one-time scan run at onboarding is not the same claim, even when both get described as “security monitoring” on a sales page.

    Verify it

    Before signing, ask to see one real example in each category: a sample restored backup log, a sample staging test note and a sample monthly report. A provider that runs these processes can produce all three without much notice.

    What good looks like

    A handful of benchmarks are worth holding any provider to, whatever else is in the pitch.

    • Restore-tested backups, on a defined schedule the provider can name.
    • A written response time, stated as a number rather than as reassurance.
    • A sample monthly report available to look at before you sign anything.

    Before you sign anywhere, NoDrama’s free website audit is a way to see what your own site’s baseline looks like.

    The questions worth actually asking before signing

    • What happens if an update breaks my site?
    • How fast will someone respond if the site goes down on a weekend?
    • Are backups actually restore-tested, or just taken?
    • Who owns the domain, hosting and admin login after this ends?
    • Is security monitoring active, or a one-time scan?
    • Can I see a sample monthly report before I sign?

    Plan structure matters here too, since a response time is often tied to the tier. See the three plans and what each covers before comparing what different providers include at a given price.

    What a generalist retainer or DIY plugin stack falls short on

    A broad, undefined-scope retainer with no report leaves nothing to check the vendor against later, since there is no record to point back to when something goes wrong. A DIY stack, a backup plugin, a security scanner and an uptime pinger stitched together, has the same gap: nobody is restore-testing those backups or applying a flagged patch, because none of those tools does that on its own. Managed hosting alone is not a substitute either. It typically does not test plugin or theme updates before they go live, and its security coverage usually stops at the server layer rather than watching the WordPress installation itself.

    Common misconceptions when comparing providers

    A few habits lead buyers to the wrong comparison, even when they are asking reasonable questions.

    The fastest response-time SLA is not automatically the right buy. A low-traffic brochure site with no checkout gets little from a 4-hour response time compared to a site where every hour of downtime costs revenue.

    Tested updates and visual regression testing are not a real differentiator among WordPress maintenance companies, since most serious providers offer some version of both. The actual gap between them shows up in response time, backup verification and report quality.

    Star ratings and testimonials do not surface how a provider behaves during a real incident. A customer who left after a bad response rarely writes up why, so the review count says little about the thing that matters most.

    Compare on the record, not the pitch. NoDrama publishes what its updates and backups actually caught, not just that they ran. Compare NoDrama against the same five criteria.

    What this does not solve

    None of the above replaces confirming a specific vendor’s process against your own site, once. A checklist tells you what to ask. It does not tell you what a specific provider will actually do when that process gets tested for real, and the only way to find that out is to ask for the sample evidence directly and read it.

    Conclusion

    Choosing among WordPress maintenance companies comes down to the same five checkable things every time: tested updates with a real rollback path, restore-tested backups, a written response time, clarity on who holds the domain and admin access, and a monthly report that reads as evidence rather than marketing. Price is a secondary filter, useful only once those five hold up on their own, not a shortcut around them.

  • Cyber Essentials Malware Protection for Your Website

    Cyber Essentials Malware Protection for Your Website

    What this guide covers

    1. 01Work out whether the website is in scope
    2. 02Confirm what covers it
    3. 03Keep it holding

    What “in scope” actually means for a website

    The current requirements document, NCSC’s Cyber Essentials: Requirements for IT Infrastructure v3.3, states the position this way: publicly available commercial web applications are in scope by default, and bespoke and custom components of web applications are out of scope. That is our summary of the document’s position rather than a confirmed word for word quotation. The exact sentence and question number need checking against the current PDF before anyone relies on it at assessment.

    WordPress core is commercial, publicly available software. A plugin or theme distributed commercially, whether paid or free, is the same kind of thing. A feature built in-house for that specific site, a bespoke booking form or a custom integration nobody else runs, is what the exclusion actually covers.

    In scope or excluded, at a glance
    In scope

    • WordPress core
    • Commercially distributed plugins
    • Commercially distributed themes
    Excluded

    • A custom-built feature or integration developed in-house for that site

    This illustrates a reading of the scope rule, not a ruling from a certification body. The assessor decides at assessment time.

    A diagram showing that commercial WordPress software is in scope for Cyber Essentials by default while bespoke, custom-built components are excluded.

    Some suppliers hear the scope question and conclude the marketing site is not in scope, because it does not look like a laptop or a server. The line above does not support that reading for a site built on commercial software. Whether a specific installation falls inside the boundary is our reading of that line, not a ruling from a certification body, and the assessor decides at assessment time.

    Verification step

    List every plugin and theme running on the site and confirm which, if any, were custom-built for that install rather than commercially distributed. Anything on the commercial list sits inside the default scope position above.

    The malware protection control itself

    The control requires an active malware protection mechanism on every device in scope. That requirement is met through one of the technical options the current requirements document defines.

    Two options are confirmed from the current text:

    Option What it requires
    Anti-malware software Kept updated in line with vendor recommendations. Prevents malware from running, prevents execution of malicious code, prevents connections to known malicious websites.
    Application allow listing Only approved applications, restricted by code signing, are allowed to execute on the device. Active approval is required before deployment.
    A table comparing the anti-malware software and application allow listing options under the Cyber Essentials malware protection control.

    Some secondary commentary on the scheme references a third option, application sandboxing. We could not confirm that option from the current requirements text this session, so we are not asserting a count either way. Treat “two options” as the confirmed position pending a direct read of the source document, and check the live text before ruling sandboxing in or out for a specific assessment.

    What a WordPress site needs to meet this

    What satisfies the control depends on how the site is hosted, and the two hosting models point at different evidence.

    A self-administered server, a VPS or a dedicated box the applicant manages directly, is itself an in-scope device. It needs a mechanism suited to a web server rather than desktop antivirus: file-integrity or malicious-code scanning that can detect injected or altered PHP, a web application firewall that blocks known malicious payloads, and the update discipline covered in the next section.

    A fully managed SaaS or PaaS platform shifts the server-level obligation to the hosting provider. The applicant’s own scope then becomes the devices used to log in and administer the site, not the server behind it.

    Verification step

    Identify which hosting model applies before deciding what evidence to gather. The two models point at different device lists and different proof.

    What a security plugin does and does not cover

    A scanning or malware-detection plugin can contribute evidence toward this control. It is not automatically equivalent to either defined option, and whether it counts is the assessor’s call, not the plugin vendor’s marketing copy.

    Verification step

    Check the plugin’s own stated capabilities against the anti-malware software option’s actual wording above, rather than assuming any plugin that markets itself as security software qualifies on that basis alone.

    The fourteen-day patching clock

    Version 3.3 introduces two auto-fail questions, one covering operating systems and firmware and one covering applications and their associated files. Each carries a fourteen-day-from-release update requirement. Missing it on either question causes automatic assessment failure, stated here as a fact of how the control works rather than a warning.

    For a WordPress site, the applications and associated files question reaches core, every plugin and the active theme. NoDrama’s website security work covers the update-testing side of keeping that clock met, which is the piece most suppliers describe finding out about only when someone asks who last patched the site.

    Verification step

    Confirm there is a standing, dated record of when core, every plugin and the theme were last updated. A memory of “recently” is not a record an assessor can check.

    What this guide does not settle

    This guide does not certify that any specific setup passes assessment. That decision belongs to the assessor reviewing the actual installation, not to a guide written in advance of it.

    It also does not resolve whether the scheme currently defines two or three technical options for malware protection. That needs a direct read of the current requirements document rather than a guess from secondary commentary.

    NoDrama’s security handling covers the scanning, tested updates and monitoring side of this control. See how NoDrama covers the website side of this control.

    See how NoDrama covers the website side of this control.

    Scanning, tested updates and monitoring, built into the WordPress security retainer.

    See Security Work

    Conclusion

    A commercial WordPress site is in scope for Cyber Essentials by default, because the scope rule excludes bespoke and custom components rather than commercial software as a class. Meeting the malware protection control on that site means matching the hosting model to the right evidence: self-administered servers need server-appropriate scanning and a WAF, managed platforms shift the server-level obligation to the provider, and keeping a dated record of the fourteen-day patching clock across core, plugins and theme. None of that is a guarantee of a pass; the assessor makes that call. For the wider picture of what a maintenance plan covers month to month, see the three plans and what each covers.

  • WordPress Security Hardening: What It Is and What It Actually Covers

    WordPress Security Hardening: What It Is and What It Actually Covers

    What this guide covers

    1. 01Understand what hardening is made of
    2. 02Sort the current advice from the stale advice
    3. 03Decide what you will run

    The short answer, and where hardening lives

    Hardening is configuration, not detection. A firewall and a malware scanner watch for something happening. Hardening removes the path it would happen down in the first place.

    Six categories make up the stack: patching, file and database permissions, administrative surface, response headers, obscurity measures, and the operational layer that keeps the rest true after a release goes out. Patching lives at the plugin, theme and core level. Permissions live on the server and in the database. The file editor and two-factor authentication live on the admin screens, and response headers get sent by the server or a proxy. A plugin cannot set a file permission or send a header the way a server configuration can.

    Six layers, three places they live
    A plugin reaches only the WordPress band

    Server

    • File and directory permissions
    • Response headers
    • wp-config.php protection

    Database

    • Reduced database privileges
    • Authentication keys and salts

    WordPress

    • File editor disabled
    • Two-factor authentication
    Update cadence spans all three bands: it is what keeps the rest of this true after a release goes out.

    No figures needed here. This is a grouping of measures by where each is configured, not a severity ranking.

    Diagram showing WordPress hardening measures grouped by where each one is configured.

    Read what ongoing WordPress security work covers once you know which of the six you actually own.

    Verification step

    List which of the six categories you can currently point at a real setting for, not a plugin dashboard toggle. The ones you cannot name are the gap this piece is about.

    How the layers actually work

    Three controls, in the order this section covers them

    File permissions
    Directories 755/750, files 644/640, wp-config.php 440/400 on suexec

    File editor disabled
    One line in wp-config.php closes the in-browser edit path

    Database and keys
    Reduced privileges, rotatable authentication keys and salts
    Diagram summarising the three controls covered in this section: file permissions, the file editor, and database privileges and keys.

    File and directory permissions

    WordPress core, wp-admin and wp-includes should be writable only by your user account. wp-content is the exception, since plugins, themes, uploads and cache write there. The handbook gives permissions as ranges, not one number: directories at 755 or 750, files at 644 or 640, and wp-config.php at 440 or 400 on a suexec setup.

    Which number is correct depends on your host. On suexec or PHP-FPM, the PHP process runs as the file owner and can use the tighter number; on a shared mod_php setup, the web server’s own user needs write access, so the same tight number breaks the site. wp-config.php gets the strictest rule, holding the database credentials and the four secret authentication keys, and the handbook calls a default 644 permission on it a hazard.

    The file editor, and why it goes first

    Setting DISALLOW_FILE_EDIT to true in wp-config.php removes the plugin and theme editor from wp-admin, equivalent to removing the edit_themes, edit_plugins and edit_files capabilities from every user. Without it, an attacker holding an admin session can paste a PHP web shell straight into a theme file through the browser, no upload needed. Removing the editor closes that path.

    Database privileges and authentication keys

    Day to day, WordPress needs only SELECT, INSERT, UPDATE and DELETE from its database user. DROP, ALTER and GRANT can be revoked without breaking anything WordPress normally does, so an injection flaw in an unpatched plugin cannot drop a table or create a privileged user, even if it succeeds.

    The keys and salts sign your authentication cookies. If they are weak, default or leaked, someone holding them can forge a valid login cookie without your password, and rotating them ends every logged in session at once, the fastest way to remove a session you do not control.

    Read the three plans and what each covers if you’d rather have someone else run this. See the three plans.

    Verification step

    After each change, load the site, log in, upload a media file and save a post. Those four actions confirm permissions, sessions and write access at once, so you know within a minute whether the tighter setting broke something.

    Security headers, including the one to stop maintaining

    The headers worth setting

    • Content-Security-Policy tells the browser which sources may load or execute. A policy that disallows unsafe-inline means an injected script tag does not run.
    • X-Frame-Options stops the page loading inside a frame on another domain, the mechanism behind clickjacking.
    • X-Content-Type-Options: nosniff stops the browser guessing a file’s type instead of trusting the declared type.
    • Strict-Transport-Security tells the browser to only connect over HTTPS for the stated period.
    • Referrer-Policy and Permissions-Policy limit what leaks to other origins and which browser features a page may use.

    X-XSS-Protection, and why guides still list it

    MDN, the reference most browser vendors defer to, marks this header both deprecated and non-standard. It “was a feature of Internet Explorer, Chrome and Safari that stopped pages from loading when they detected reflected cross-site scripting (XSS) attacks.” Chrome and Edge have since removed the XSS auditor the header controlled, so setting it today changes nothing.

    MDN’s own guidance is direct: “it is recommended that you use Content-Security-Policy instead of XSS filtering.” It warns that in some cases the header “can create XSS vulnerabilities in otherwise safe websites,” which makes it a header that can work against you.

    The honest answer to what people are searching for is this. Do not tune this header. Retire it, and put the effort into Content-Security-Policy, which is harder to get right and is the one doing the actual work.

    Header What it does Status
    Content-Security-Policy Tells the browser which sources may load or execute Set it, does the actual work
    X-Frame-Options Stops the page loading inside a frame on another domain Set it, stops clickjacking
    X-Content-Type-Options Stops the browser guessing a file’s type instead of trusting the declared type Set it, stops MIME sniffing
    Strict-Transport-Security Tells the browser to only connect over HTTPS for a stated period Set it, forces HTTPS
    Referrer-Policy Limits what leaks to other origins on navigation Set it, limits leakage
    Permissions-Policy Limits which browser features a page may use Set it, limits feature access
    X-XSS-Protection Once stopped some browsers loading pages with detected reflected XSS Deprecated per MDN, retire it

    Status described in words, not header syntax to copy. No HSTS max-age value shown, since that number is sourced only to a secondary vendor article.

    Chart of WordPress security response headers with the deprecated X-XSS-Protection marked.

    Read about how response headers and caching are handled for performance if headers are new territory for you.

    Verification step

    Request your own home page and read the response headers back. Then check a page that loads a third party script or embed, since a policy that passes cleanly on the home page often blocks something the moment an embed is involved.

    What good looks like

    The configuration is set, and somebody can say when each item was last checked. Updates are applied on a schedule, tested before going live, and reversible if one breaks something. That is ordinary practice offered by several providers, not something unique to any one of them. The plugin inventory is short, and every item on it is still maintained upstream.

    Patchstack, a vendor that sells a vulnerability monitoring product, published figures worth reading with that in mind:

    Layer Share of 2025 disclosures
    Plugins Roughly 91 percent
    Themes Roughly 9 percent
    Core 6 vulnerabilities, out of 11,334 total
    Table showing that most WordPress vulnerabilities disclosed in 2025 were in plugins. 11,334 total disclosures, a 42 percent increase on 2024. Shares are rounded. All figures from Patchstack, a vendor with a commercial interest in this figure, not an independent survey.

    Read how updates get tested before they go live once you know the plugin layer is where the exposure actually sits.

    Verification step

    Pick the three most recently updated plugins on your site and find out who applied each update and whether anything was checked afterward. If you cannot answer either question, that is the gap.

    What to do about it

    In order of what returns most for the effort:

    01

    Audit your plugins and themes and remove what is not used.

    02

    Disable the file editor, one line in wp-config.php.

    03

    Tighten wp-config.php permissions, then the directories, testing after each.

    04

    Set the current header set, and remove X-XSS-Protection if it is there.

    05

    Reduce the database user’s privileges and rotate the keys.

    06

    Decide who applies and tests updates, and on what cadence.

    Verification step

    After each change above, run the same four checks from the permissions section again: load the site, log in, upload a media file, save a post. A hardening change you cannot confirm is a change you are trusting rather than one you have made.

    Would rather not run this list yourself?

    See what hardening is included in NoDrama’s WordPress security retainer.

    See Security Work

    Common misconceptions

    “A security plugin is hardening.”

    It firewalls, scans and limits login attempts: detection, not configuration.

    “Changing the table prefix and admin username secures the site.”

    The handbook frames this as obscurity, stopping scripted attacks rather than a targeted one. Cheap and worth doing, not a defense on its own.

    “Core updates are the priority.”

    6 of the 11,334 vulnerabilities disclosed in 2025 were in core, and core auto-updates already cover most of that.

    “My host handles security.”

    Hosting-level protection is a different layer from the application-level configuration described here.

    What this does not cover

    The exact permission numbers for your host, which depend on how it runs PHP. Writing a Content-Security-Policy for your specific third party scripts. Incident response and cleanup after a compromise. And no formal certification: hardening supports compliance work, not a compliant status.

    Where this leaves your site

    Hardening is a stack of configuration changes, most of it living outside WordPress itself: the server, the database, the response headers. It holds only as long as somebody keeps patching the layer where the vulnerabilities actually are, plugins rather than core.

  • How Often Should a WordPress Site Be Updated?

    How Often Should a WordPress Site Be Updated?

    In this guide

    1. 01Work out what you actually have.
    2. 02Set the cadence and apply it.
    3. 03Confirm it held.

    What “keeping WordPress updated” actually means

    WordPress core, plugins, and themes do not run on the same update mechanism, and that gap is where most of the confusion about update frequency comes from.

    Core minor releases, the point releases that fix security holes and bugs, install themselves automatically on any WordPress site running a reasonably current version, with no admin action required. Core major releases, roughly one every four months, do not install themselves on an existing site unless the owner opts in.

    Plugins and themes are manual by default, unless the WordPress security team decides a vulnerability is severe enough to force a patch through the update API. Outside that forced-patch exception, every plugin and theme update is something the site owner has to apply.

    That split gives a practical rule: a security-flagged release gets a short, defined window. A feature or maintenance release gets batched with the rest and applied on a schedule. NoDrama patches security releases with key pages photographed before and after, and puts back anything that breaks.

    Check what you have now

    Two things to check before setting a policy. First, whether WP_AUTO_UPDATE_CORE is set to minor, true, or false in wp-config.php, since that constant governs core only. Second, which plugins and themes already have auto-updates toggled on, under the Plugins and Themes screens in the dashboard.

    Working out how often to update WordPress plugins on a given site starts with what is already switched on, not with a fixed number.

    Verify it

    List every plugin and theme with auto-update turned on, and confirm someone is actually watching the ones that are not. A setting nobody checks is not a policy.

    Start with a free audit of your current update settings to see where the site actually stands.

    Choose the right cadence

    A workable WordPress update schedule has two real values, not one.

    Anything security-flagged gets a short, defined window, commonly discussed as 24 to 48 hours once it has passed staging. That is industry-common practice, not a NoDrama response-time commitment: NoDrama’s confirmed response times are 4 hours on The Standard, 2 hours on The Higher Standard and 1 hour on The Highest Standard, if a site is down or hacked, and that is a different clock from how fast a patch itself gets classified and tested.

    Everything else, a feature release, a maintenance update, a routine plugin bump, runs on a batch: weekly for most sites, monthly for sites with very little at stake.

    Update type Cadence Trigger
    Core minor (security, bug fixes) Automatic, on WordPress’s own schedule No action needed
    Core major Roughly every 4 months Opt-in on existing sites
    Plugin or theme, security-flagged Short window, commonly 24 to 48 hours, once staging has passed Vulnerability disclosure
    Plugin or theme, routine Weekly to monthly batch Scheduled review
    A table comparing WordPress core, plugin and theme update cadences by type. The 24 to 48 hour window is common practice this piece recommends, not a stated NoDrama SLA.

    The advice this replaces is “update everything the moment a notification appears.” That is the habit that breaks sites, because it skips the step that matters: classify first, security or feature, then apply on the clock that matches. The major release cycle runs on roughly a four-month scoping-to-launch cadence, one more reason a single interval was never going to cover everything WordPress ships.

    For a low-traffic, no-commerce site

    The defaults are a reasonable position here: core minor auto-on, plugins and themes manual, checked monthly. There is not much for an untested update to break, and not much riding on catching it fast.

    For a site with checkout, forms, or client data

    The case for a tighter cadence and staging gets stronger, not because the site is more exposed in the abstract, but because there is more attached to an update going wrong: a broken checkout, a form that silently stops submitting, and a customer finding out before the owner does.

    Apply the change

    To prevent a theme from being able to update on its own, without turning off updates everywhere, WordPress gives you a filter rather than a blanket setting. The auto_update_theme filter is the documented route, and the call that disables it for a single theme is:

    add_filter( 'auto_update_theme', '__return_false' );

    Place that in a plugin file, not directly in wp-config.php. The WP_AUTO_UPDATE_CORE constant in wp-config.php governs core only and does not touch theme auto-updates at all.

    For per-theme control instead of a blanket switch, check $item->slug inside a custom callback on the same filter, rather than returning false for every theme on the site.

    The core-only equivalent lives in wp-config.php: the WP_AUTO_UPDATE_CORE constant, set to false, true, or the string ‘minor’.

    Via code

    For an owner comfortable editing a plugin file or wp-config.php, the filter and the constant above are the whole job.

    Via a managed maintenance plan

    The alternative is having the classify-then-stage-then-test sequence run on the owner’s behalf rather than by the owner: someone else watches for the release, decides whether it is security or routine, and applies it on the matching clock.

    See how NoDrama classifies and patches WordPress updates, with key pages checked before and after.

    Verify it

    After either path, confirm the setting took place. Check the Site Health screen or the auto-update column on the Plugins and Themes screens, rather than assuming the change was saved.

    Verify safely

    Verifying an update safely means testing on staging, not checking the live site after the fact. Apply the update on a copy of the site, not a preview mode on the same install, then load the front page, the key templates, any forms, checkout if the site has one, and the admin login before promoting the change to production.

    The safe-update sequence

    1. 01
      Backup taken
      Files and database together, immediately before.

    2. 02
      Staged
      Applied to a copy of the site, not the live install.

    3. 03
      Tested
      Front page, templates, forms, checkout, admin login.

    4. 04
      Promoted or held
      Passes, it ships. Fails, it stays on staging.

    5. 05
      Verified live
      Same checks again on production, not a homepage glance.

    This is one common sequence, not the only one. NoDrama runs updates on the live site with key pages photographed before and after, and puts back anything that breaks.

    A flow diagram of the staging, testing and promotion sequence for a WordPress update.

    The rollback path only works if a backup was taken immediately before the update, restoring files and the database together, not one without the other. Here’s how backups and rollback actually work once a change needs undoing.

    Verify it

    After promoting, confirm the update on the live site the same way it was checked on staging, the front page, templates, forms, and checkout, not just a glance at the homepage.

    Troubleshoot

    The update went live, and something broke.

    Restore from the backup taken immediately before the update, files and database together, ahead of trying to manually undo a single plugin. Reversing one change by hand risks missing whatever else the update touched.

    WordPress emailed me about a critical error.

    That is Recovery Mode, a built-in fallback that lets an admin log in with the offending plugin or theme paused so it can be deactivated without FTP access. Recovery mode catches fatal errors. It does not catch a page that loads but looks wrong, which is what the staging and test step is for.

    What this does not solve

    Uptime and error monitoring tells you the site is down or throwing an error. It does not tell you an update quietly slowed the site down or broke one form without triggering an error. Catching that needs the staging and test step, not a monitoring alert.

    The short answer, restated

    So, how often should WordPress be updated? Core patches its own security releases without anyone touching it. Everything else, plugins and themes, runs on a policy: fast for anything security-flagged once it is tested, batched weekly or monthly for the rest, and tested on staging before it goes live either way. See the three plans and what each covers if a managed policy is the simpler route.