WordPress Security & Performance Consultant

Yes, and I maintain WordPress sites for a credit union with over $2B under management, a fintech, and a defense-adjacent manufacturer, all under recurring external audit. Core WordPress is not the weak point. Poorly written plugins, abandoned code from previous developers, unpatched dependencies and wide-open login endpoints are.\n\nWhat regulated clients need is not a different CMS. It is scanning, patching, hardening at the edge, and someone who works through audit findings on a schedule.

It sits between your visitors and your server, which means it can do three things no plugin can:

• Block traffic before it reaches you, WAF rules, bot and DDoS mitigation, rate limiting and country or ASN restrictions, all applied before a request costs your host anything.
• Serve pages from the edge, so most visitors never touch your origin server. On one publishing client that is better than 90% of page requests.
• Control headers centrally, security headers delivered by a worker rather than PHP, so they apply to every response and cannot be bypassed by a plugin.

The catch is that none of it configures itself, and the default settings are deliberately conservative.

Scans run daily against reputable vulnerability databases, checking your specific plugin, theme and core versions against known CVEs and wpscan.io reports. Alerts go to real recipients rather than a dashboard nobody opens.\n\nThe part that matters is what happens next: I verify each alert by hand, because scanners produce false positives, then patch, mitigate or document why it does not apply. For clients enrolled in CISA's federal scanning program, those monthly reports get the same treatment.

A CSP tells the browser which scripts, styles, frames and images are allowed to load at all. It is the control that stops an injected or compromised third-party script from running, and security audits increasingly require one.\n\nIt is also the single most likely thing to break your site if deployed carelessly. My approach is report-only mode first, collecting violations from real traffic, whitelisting asset by asset, then enforcing, with payment frames, e-signature flows and video embeds tested individually.

Caching only helps requests it can serve. Common causes I find behind a cache that is not helping:

• A cart, session or tracking cookie causing the edge to bypass cache on every single request.
• Expensive queries and ACF lookups running on uncached routes or logged-in views.
• Render-blocking CSS and JavaScript, which caching does not touch at all.
• Full-size images served at thumbnail dimensions.
• Third-party scripts, chat widgets and video embeds loading before first paint.

None of those are fixed by adding another plugin.

By profiling the specific page, not by chasing a score. LCP usually comes down to hero imagery and render-blocking assets, CLS to images and embeds without reserved space and to fonts swapping late, INP to heavy JavaScript on interaction.\n\nThe fixes go into the theme: correctly sized WebP images through a CDN, CSS split into modules loaded on demand, fonts loaded conditionally, video embeds replaced with click-to-load previews, and HTML minified to bring TTFB down. Then I verify against field data rather than a single lab run.

Usually not. Raising the memory limit hides it for a while, but the cause is normally in the database or in code: duplicated postmeta rows, orphaned revisions and transients, an abandoned plugin leaving a drop-in behind, or a template running thousands of queries.\n\nOn one client the database was 63% duplicate postmeta, roughly 600,000 rows. Removing them, repairing the tables and enabling object caching solved memory errors that had been attributed to hosting for months.

Yes, within limits. I review access and error logs to establish what happened, remove injected code and abandoned writable directories left by previous developers, patch the entry point, rotate credentials and lock down the paths that were used.\n\nWhat I do not do is forensic incident response for a breach involving customer data. That needs a specialist firm and, usually, your counsel. I will tell you plainly when you are past the line.

Everything is built locally, verified on staging, and deployed through git with zero-downtime releases. Security rules go out in report-only or test mode where the platform supports it. Cloudflare changes are made with the firewall event log open, so a rule that starts blocking legitimate traffic is caught in minutes rather than reported by a customer next week.

Both exist, but the ongoing version is what actually holds. A hardening and speed project fixes today's state; new plugins, new marketing tags and a redesign in eight months erode it.\n\nMost of my clients run this inside a monthly retainer: scans and alerts triaged, audit findings worked through, vitals tracked, updates tested and deployed, and new third-party scripts reviewed before they ship.