Audit My Site Get Started

Category: IT or ops leader

  • 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.

  • 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.

  • What Are the Security Risks of WordPress?

    What Are the Security Risks of WordPress?

    Contents

    1. 01Understand where the risk actually sits. The short answer, and how it actually works.
    2. 02See why it matters for your site. Why it matters for your situation, and what good security discipline looks like.
    3. 03Know what to do and what still isn’t covered. What to do about it, and the common misconceptions.

    The short answer on WordPress security risks

    Of 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, 91 percent were found in plugins, 9 percent in themes, and only 6 low-priority issues were in core, per Patchstack’s 2026 State of WordPress Security whitepaper. That split is not close. Core’s share is statistically negligible against plugins alone.

    The direct implication follows from the numbers, not from opinion: WordPress the platform is not where the risk sits. The unaudited third-party code running on top of it, chosen and installed by whoever manages the site, is.

    How WordPress security risk actually works

    Why plugins and themes carry the risk core does not

    Core ships from a single, reviewed codebase. It’s maintained by a security team of more than 50 people who backport fixes to older versions rather than forcing every site onto the newest release to stay patched, per the WordPress Security Team’s own review process.

    A plugin or theme is a different situation entirely. It’s an independently authored package, written by a separate developer of whatever skill level they happen to have. WordPress.org’s directory review checks a plugin at submission, but it doesn’t continuously re-audit every version update that ships after that. A plugin that passed review in 2022 can ship a vulnerable update in 2026 with no equivalent second check.

    This is also where the cost math changes. Verified, tested updates catch the failure mode where a legitimate patch breaks something on the live site, which is a different problem from a plugin’s own code carrying a vulnerability in the first place. See what tested, verified updates actually cost to have covered for how that piece works.

    Verify it

    For any plugin you’re evaluating, check whether it names a security team or a documented disclosure process on its own listing page. A plugin with neither has no equivalent of core’s review process behind it.

    The four vulnerability classes behind nearly all plugin and theme issues

    Nearly all of the 91 percent plugin figure and the 9 percent theme figure comes down to four recurring mechanisms, as WordPress’s own definitions of these vulnerability classes lay out.

    SQL injection

    Unsanitized input gets run as a database command instead of passed through a prepared statement.

    Cross-site scripting (XSS)

    Unescaped output lets attacker-supplied JavaScript run in a visitor’s or an admin’s browser.

    Cross-site request forgery (CSRF)

    A state-changing action fires using a logged-in admin’s own session, because the plugin skipped its nonce check.

    Broken access control

    A user reaches an action or a piece of data that should have required a higher capability level.

    Four cards covering SQL injection, XSS, CSRF, and broken access control, each with a one-line description of how it occurs.

    A nonce, in WordPress’s own terminology, is a Number Used Once. It’s the mechanism a plugin is supposed to check before it lets a state-changing action run, and a missing nonce check is what turns a normal admin action into a CSRF opening.

    Verify it

    For a specific plugin, check its own changelog for language like “sanitization,” “escaping,” or “capability check” fixes. That’s usually the tell that one of these four classes got patched in that release.

    Why this matters for a site you are responsible for

    An outdated plugin isn’t a slow decay. It’s a published map. Once a vulnerability is disclosed along with its fix, any site still running the unpatched version becomes identifiable by version fingerprinting and targetable at scale by automated tools, per WordPress’s own hardening guidance, which states plainly that the exploit information for a disclosed vulnerability is almost certainly in the public domain once the fix ships.

    An inactive plugin doesn’t remove that exposure. Its files still execute if they’re present on the server and registered, deactivation just stops the plugin from loading on the front end, it doesn’t delete the code. If you’re not using a plugin, delete it rather than deactivating it and leaving it there.

    The same logic that connects an unmaintained site to slow performance connects it to exploitability: both come from code nobody is watching. See why an unmaintained site slows down the same way it gets exploited for how that overlaps.

    What good security discipline actually looks like

    Running fewer, well-maintained plugins from established developers who patch quickly is a real, measurable reduction in risk. Risk scales with how many separate third-party codebases a site is running, not with running WordPress itself.

    Severity is the other variable worth watching directly. A high-severity vulnerability, 17 percent of 2025’s total per Patchstack, is associated with likely mass-scale, automated exploitation. That’s the practical test for how urgently a given patch matters: a plugin that’s unmaintained, has a large install base, and handles user input or authentication is high-risk regardless of how small it feels in your own stack.

    See what a maintenance plan should actually include for how that discipline gets specified rather than assumed.

    What to do about it

    1. 01Delete plugins you’re not using. Deactivating leaves the files on the server, where they still execute if registered.
    2. 02Check whether a plugin’s developer is still actively patching it. An abandoned plugin stays exploitable no matter how quickly you’d apply an update if one existed.
    3. 03Apply security updates on a defined schedule. Not whenever someone happens to remember.
    4. 04Confirm updates are tested in staging before they go live. A legitimate security patch can still break site functionality when applied blind, which is a different failure than the vulnerability it patches, and both need a fix.

    Not sure how many plugins on your site are still actively maintained?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    Verify it

    After any update, confirm the site still renders and the admin dashboard still loads before considering the patch applied. A rollback path only helps if someone checks that it worked.

    Common misconceptions about WordPress security

    “WordPress itself is insecure.”

    Core’s share of 2025’s disclosed vulnerabilities was 6 low-priority issues, statistically negligible against plugins’ 91 percent. The platform isn’t the risk. The unaudited third-party code running on top of it is.

    “A security plugin covers this.”

    A security plugin helps with detection and hardening, but it doesn’t patch a vulnerable plugin’s own code. That code stays vulnerable until its own developer ships a fix, or a virtual-patching rule addresses it in the meantime.

    “Popular plugins are safer.”

    Popularity increases how worthwhile a plugin is to build an automated attack against. It doesn’t guarantee the code was reviewed for the four vulnerability classes above.

    Getting this in writing matters as much as getting it right in practice. See what a maintenance plan should actually specify about updates for the language that closes that gap.

    What this does not solve

    Tested updates and staged rollback catch the case where a legitimate patch breaks something. They don’t find an undisclosed, zero-day vulnerability, and they’re not a substitute for a web application firewall or real-time malware scanning.

    This guide isn’t a claim that any specific site is, or isn’t, currently compromised.

    So, what are the real security risks of running WordPress?

    The risk sits in the plugins and themes running on top of core, not in core itself, and it concentrates further in whatever is outdated, abandoned, or simply numerous. Fewer, actively maintained third-party codebases is the practical lever, not switching platforms.

  • Why Is My WordPress Site So Slow?

    Why Is My WordPress Site So Slow?

    Contents

    1. 01Work out which layer is slow. What “slow” actually means, and confirming where the time is going.
    2. 02Fix the layer that is actually slow. The three ways to fix it, from easiest to most manual.
    3. 03Confirm it is held and stop it from recurring. Verify the fix, troubleshoot the remaining edge cases, and keep it from coming back.

    What “slow” actually means for a WordPress site

    Slow is a number, not a feeling. Two numbers, in fact: time to first byte, the gap between the browser asking for the page and the server sending back the first byte of a response, and render time, how long the browser then takes to paint and settle the page a visitor actually sees.

    Google measures both through Core Web Vitals, assessed at the 75th percentile of real visits so one fast or slow load does not skew the picture. Largest Contentful Paint (LCP), the render time of the largest image or text block in the viewport, is good at 2,500 milliseconds or under. Interaction to Next Paint (INP), how quickly the page responds to a visitor’s interactions across the whole visit, is good at 200 milliseconds or under. Cumulative Layout Shift (CLS), the sum of unexpected layout shifts as the page loads, is good at 0.1 or under.

    Server response (TTFB)

    Hosting, plugins running on every request, and database queries.

    Above ~600 to 800ms flags a server-side problem

    Page weight

    Full-size images and the theme’s full CSS and JavaScript bundle.

    LCP good at 2,500ms or under

    Browser rendering

    Render-blocking scripts, stylesheets, and third-party embeds.

    INP good at 200ms or under, CLS at 0.1 or under

    All three vitals are measured at the 75th percentile of real visits. These are Google’s general Core Web Vitals thresholds, not WordPress-specific ones.

    A slow WordPress site usually comes from one of three places:

    Server-side load.

    The hosting environment, an overloaded database, or plugins that run heavier queries than they need to.

    Unoptimized front-end weight.

    Full-size images, render-blocking scripts and stylesheets, or a theme that loads its entire CSS and JS bundle regardless of what the page uses.

    No caching layer.

    Every visit reprocesses the same PHP and database work from scratch instead of serving a version already built.

    Which one applies to your site is not a guess. It is the next step.

    Confirm where the time is actually going

    Run a PageSpeed Insights check, or look at the field-data Core Web Vitals for the page, before you change anything. That gives you a TTFB number and a render-time picture to compare against once you have made a change.

    If TTFB alone is high, roughly above 600 to 800 milliseconds before any content starts, the problem is server-side: the hosting environment, the plugins running on every request, or the database being asked the same questions too many times.

    If TTFB looks fine but the page still finishes rendering slowly, the problem sits in the front end: images, render-blocking CSS or JavaScript, or third-party scripts like chat widgets, ad tags or web fonts loading synchronously.

    Verify it

    Write down the specific number, TTFB, and the Core Web Vitals reading before you touch anything. That is the only way to confirm a fix actually moved it rather than assuming it did.

    Fix it

    Option 1, easiest, recommended: page caching plus image compression

    A page cache stores the fully rendered HTML after the first PHP and database cycle runs, then serves that stored copy on repeat requests instead of running PHP and the database again. Paired with image compression, this catches the two most common causes on a typical site: repeat-visit server load and oversized static assets.

    What it misses matters as much as what it catches. A page cache does not cover logged-in visitors, cart or account pages, or any URL with a query string, all excluded from caching by design because that content is meant to be dynamic. If your slow pages are the ones a logged-in user or a shopper sees, caching alone will not touch them.

    This is also the baseline a maintenance plan should already be checking as part of ongoing upkeep, not a one-time install and forget.

    Verify it

    Re-check the TTFB and Core Web Vitals numbers from the section above, on the same page, after the cache has had time to build.

    Option 2, done for you: a CDN plus performance work as part of a managed plan

    A content delivery network (CDN) serves cacheable static assets, images, CSS, JavaScript, from an edge node physically closer to the visitor, and keeps a pre-warmed connection open to the origin server. The first request for a given asset is an origin pull, fetched from your server and cached at the edge. Every request after that is served from the edge until the cache expires.

    What a CDN cannot do is speed up PHP execution, database queries, or anything generated dynamically at the origin server on every request. If the slowness is server-side, a CDN sits on top of the problem without reaching it.

    Caching plugin CDN
    Logged-in pages Not cached Not cached
    Cart or account pages Not cached Not cached
    Static assets (images, CSS, JS) Cached at origin Cached at edge, closer to visitor
    Dynamic HTML (PHP, database output) Not touched Not touched
    Table comparing what a caching plugin and a CDN each cover, showing both miss logged-in pages and cart pages, and neither speeds up dynamic HTML.

    See how the CDN and performance work is scoped as part of a managed plan, since CDN allocation and the performance work around it are handled as ongoing configuration rather than a one-time setting.

    Verify it

    Confirm the origin pull happened (the first load of an asset after a change) and that the second load of the same asset comes from the edge, then re-check TTFB against the number you noted earlier.

    Option 3, manual: clean the database and audit plugins one at a time

    Post revisions, spam comments, expired transients, and orphaned tables accumulate in the WordPress database over time and are not purged automatically. Every uncached query against a bloated database takes measurably longer than the same query against a clean one.

    Deactivating plugins one at a time is a reasonable way to find an obvious offender, a single plugin running an expensive query on every page load. It is the longest path of the three, and it will still miss the cumulative database bloat, image weight, and theme bloat that no single plugin caused on its own.

    Verify it

    After cleaning the database or deactivating a plugin, re-run the same TTFB check and confirm the number moved before assuming the change worked.

    Verify the fix actually worked

    Re-run the same check you used to note the original number on the same page, cold. Not immediately after clearing a cache, since the first load after a cache clear rebuilds the cache and will look artificially slow. Compare the new TTFB and Core Web Vitals reading against the number you wrote down at the start. If it has not moved, the fix touched the wrong layer.

    Troubleshoot

    The site is fast on desktop but slow on mobile.

    Mobile and desktop Core Web Vitals are measured and reported separately. A fix that improves desktop LCP or INP does not automatically carry over to mobile field data. Check the mobile-specific numbers directly rather than assuming a desktop result applies.

    I installed a CDN, and nothing changed.

    This is the direct symptom of a server-side bottleneck a CDN cannot reach. A CDN only speeds up cacheable static assets served from the edge. If TTFB was already the problem, adding a CDN leaves it untouched. Re-check TTFB specifically rather than the overall load time.

    It’s fast for me but slow for everyone else.

    You are likely viewing a warmed, cached, or logged-in version of the page that a first-time or logged-out visitor does not get. Check the page from a logged-out session, ideally on a different network, before concluding the fix worked for everyone.

    Prevent it recurring

    Run the same diagnostic monthly, not just after a complaint. A monthly health report that tracks TTFB and Core Web Vitals over time catches drift before it becomes a complaint, which is what a monthly health report actually tracks as part of ongoing maintenance.

    Not sure which layer is slowing your site down?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    What this does not solve

    The diagnostic above finds and addresses the common causes: server load, page weight and missing caching. It does not replace hosting that is genuinely undersized for a high-traffic site, where the fix is a hosting change, not a configuration one. It also does not audit custom code written specifically for your site, since that requires a developer familiar with the codebase, not a maintenance diagnostic.

    Google has publicly confirmed that page speed is a ranking signal. This piece does not quote a specific figure for how much it weighs, because no verifiable figure exists to quote.

    Unmaintained plugins that slow a site down are often the same plugins carrying real security exposure, so a speed audit and a security review usually turn up the same list.

    So, why is your WordPress site actually slow?

    It comes down to one of three layers: server response time, page weight, or browser rendering, and the fix depends on which one the diagnostic points to. Check TTFB first. A high number means the problem is server-side. A fine TTFB with a slow finish means the problem is in what the browser has to load and render. Fix the layer the numbers point to, not the layer that is easiest to buy a plugin for, and re-check the same numbers afterward to confirm it held.