DEV Community: devautomation

WordPress security: the 10-minute monthly checklist that catches real problems

devautomation — Wed, 20 May 2026 17:53:06 +0000

Most WordPress security advice is useless.

"Use a strong password." "Keep plugins updated." "Install a security plugin."

These are fine, but they don't tell you what to actually check each month on client sites. Here's what I check -- based on the actual vulnerabilities and incidents I've seen managing sites for paying clients.

Why 10 minutes and not an hour

A 10-minute monthly check that actually happens is infinitely better than a comprehensive quarterly audit that gets skipped.

The goal isn't perfect security -- it's catching the 80% of problems that show up most often before they become incidents.

The monthly checklist

1. Verify WordPress core and plugins are current (2 min)

wp --allow-root core check-update
wp --allow-root plugin list --update=available --format=table

Plugins with known CVEs get exploited within days of disclosure. Being current matters more than any security plugin.

What to watch for: Plugins not receiving updates for 6+ months. These become unpatched vulnerabilities. Deactivate and replace them.

2. Check for default admin username (30 sec)

wp --allow-root user get admin --field=login 2>/dev/null && echo "WARNING: user admin exists"

Still the most common brute-force target. If a client's site has a user named "admin" with editor or admin role, rename it.

wp --allow-root user update admin --user_login=something_else

3. Verify wp-config.php permissions (30 sec)

stat -c "%a" /path/to/wp-config.php

Should be 600 or 640. If it's 644 or 777, fix it:

chmod 600 /path/to/wp-config.php

644 means any process on the shared server can read your database credentials.

4. Check for exposed debug.log (30 sec)

[ -f /path/to/wp-content/debug.log ] && echo "WARNING: debug.log exists" || echo "clean"

Debug logs often contain: database credentials, API keys, internal paths, email addresses, and error messages that reveal vulnerability details. If it exists, read it before deleting it -- then delete it.

Also check that WP_DEBUG_LOG is disabled in wp-config.php on production sites.

5. Audit admin users (2 min)

wp --allow-root user list --role=administrator --fields=ID,user_login,user_email,user_registered

Compare against who should have admin access. Former employees and contractors frequently retain admin accounts. Anyone not recognized: disable immediately.

wp --allow-root user delete USER_ID --reassign=1

6. Check for world-writable PHP files (1 min)

find /path/to/wordpress -name "*.php" -perm /o+w 2>/dev/null

Any output is a problem. World-writable PHP files can be modified by other users on shared hosting or by malware. Fix:

find /path/to/wordpress -name "*.php" -perm /o+w -exec chmod o-w {} \;

7. Review recent logins for anomalies (1 min)

Install the WP Last Login plugin (free) or use Wordfence logs. Look for:

Logins from unexpected countries
Multiple failed login attempts followed by success
Logins at unusual hours for that client

If something looks wrong: force password reset on that account immediately.

8. Check SSL certificate expiry (30 sec)

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

An expired SSL breaks contact forms, ecommerce checkouts, and admin logins. Set a calendar alert for 30 days before expiry. Better: automate renewal with Let's Encrypt + certbot.

9. Verify backups ran (1 min)

Check your backup plugin's last successful run date. If it's more than 2 days ago for a WooCommerce site, or more than 7 days for a static site, something is wrong.

Also check that the backup destination is off-server. Backups on the same hosting account as the site don't protect against:

Hosting account compromise
Host-side data loss
Account suspension

10. Run a quick malware scan (2 min)

Wordfence (free tier) does a file integrity check:

wp --allow-root wordfence scan

Or check core file integrity manually:

wp --allow-root core verify-checksums
wp --allow-root plugin verify-checksums --all

Modified core or plugin files that don't match the official checksums indicate tampering. Investigate before dismissing.

The red flags that need immediate action

These aren't monthly checks -- they're things to act on the moment you see them:

Unknown admin users -- potential backdoor account
Core or plugin files modified without a recent update -- likely compromise
Sudden traffic spike with no marketing campaign -- bot activity or exploit
Site redirecting visitors to another domain -- active malware
Contact form sending spam -- either compromised or open relay

If you see any of these: put the site in maintenance mode first, investigate second.

Automating this

Running these checks manually across 10 client sites takes about an hour per month. The WP-CLI commands above work well in a script that loops over your client list and emails you a report.

The approach: each check writes a pass/fail to a log, then the script generates an HTML summary. If anything critical is flagged, it sends an alert email immediately.

Free checklist + the automation bundle:

WordPress Monthly Maintenance Checklist -- free download, covers security + everything else
WordPress Agency Automation Bundle -- the scripts that automate these checks across all your sites

What security issues do you encounter most often on client WordPress sites? Brute force, compromised plugins, or something else?

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

MainWP vs ManageWP vs custom scripts: how I manage 15+ WordPress sites in 2025

devautomation — Wed, 20 May 2026 17:46:39 +0000

Managing multiple WordPress sites for clients is a solved problem -- but the solution depends on how many sites you manage and what your actual bottleneck is.

I've used all three approaches. Here's when each one makes sense.

The three real options

ManageWP -- cloud-hosted dashboard, monthly subscription (~$2/site or $100+/month flat), handles updates, backups, uptime, performance checks. Polished UI.

MainWP -- self-hosted on your own WordPress install, free core, paid extensions for advanced features. You own the data.

Custom scripts -- WP-CLI + SSH + your own automation. Free forever, runs exactly how you want, no third-party dependencies.

ManageWP: best for non-technical agency owners

ManageWP is the easiest to set up and the easiest to explain to clients. The dashboard looks like a proper SaaS product.

Strengths:

Cloud-hosted (no maintenance of the dashboard itself)
White-label client reports that look professional
Good uptime monitoring
One-click safe updates (tests after updating)
Works with WooCommerce

Weaknesses:

Gets expensive at scale. 20 sites at $2/site = $40/month. 50 sites = $100+/month.
You're dependent on their infrastructure. If ManageWP has downtime, so does your monitoring.
Less customizable -- you get what they give you
Premium features (performance checks, SEO audits, etc.) add cost quickly

Best for: agencies managing 5-20 sites who want a polished tool and don't mind paying for it.

MainWP: best for large volumes and data ownership

MainWP installs on a WordPress site you control. Your data stays yours.

Strengths:

Free core with no per-site fees
Good extension ecosystem
Works well at 50+ sites
You control the data and the dashboard

Weaknesses:

You're now managing another WordPress site (the MainWP dashboard)
Extensions add up: advanced reports, client portal, vulnerability scanning are paid
Requires more setup than ManageWP
The child plugin must be installed on every site you manage

Best for: agencies with 20+ sites who want to own their data and avoid per-site pricing.

Custom scripts: best for technical freelancers who want full control

If you're comfortable with the command line, WP-CLI + SSH + bash/PowerShell gives you more flexibility than either dashboard solution.

The basic flow:

#!/bin/bash
# Run on one client, or loop over clients.json for all
WP_PATH="/var/www/html/client"

# Backup first
wp --path="$WP_PATH" --allow-root db export backup_$(date +%Y%m%d).sql

# Update everything
wp --path="$WP_PATH" --allow-root core update
wp --path="$WP_PATH" --allow-root plugin update --all
wp --path="$WP_PATH" --allow-root theme update --all

# Check for issues
wp --path="$WP_PATH" --allow-root doctor check --all

Strengths:

Zero monthly cost
Runs on your schedule, not a third party's
Fully customizable (add any check you want)
Generates reports exactly how you want them
No dependency on external services staying online
Handles edge cases that dashboards don't

Weaknesses:

Takes time to build (10-15 hours upfront)
Requires SSH access to servers (not always available on shared hosting)
No visual dashboard (unless you build one)
Debugging when something goes wrong requires CLI knowledge

Best for: technical freelancers managing 8+ sites who want the lowest possible ongoing cost and maximum control.

The math: what each approach actually costs

Assuming 15 sites, 2 hours/month manual time per site without automation:

ManageWP ($2/site):

Monthly cost: $30
Time: ~3 hours/month reviewing dashboards + handling flagged issues
Annual: $360 + ~36 hours of your time

MainWP (free core + $100/year extensions):

Monthly cost: ~$8
Time: ~3 hours/month + occasional dashboard maintenance
Annual: ~$100 + ~36 hours of your time

Custom scripts (built once):

Monthly cost: $0
Build time: 12-15 hours (one time)
Monthly time: ~45 minutes reviewing automated reports
Annual: $0 + ~9 hours of your time

At $80/hour, the time saved by custom scripts vs ManageWP:

ManageWP: 36 hours x $80 = $2,880 in time + $360 in fees = $3,240/year
Custom scripts: 12 hours build + 9 hours/year = 21 hours x $80 = $1,680 year one, $720 year two onward

Custom scripts break even in year one and cost 80% less by year two.

What I actually use

I use all three, depending on the client:

ManageWP: clients who want a client portal and professional white-label reports. I bill the ManageWP cost to the client.
Custom scripts: my standard setup for most clients. Free, runs exactly as I need.
MainWP: inherited from a previous agency setup. I'm gradually moving those sites to scripts.

For the sites on custom scripts, I run a maintenance script that handles updates, backups, security checks, and HTML report generation -- one command per site, or one command for all sites via a JSON config file.

Which should you choose?

Choose ManageWP if:

You're less technical and want a polished dashboard
You have fewer than 20 sites
You can bill the cost to clients
You want one-click safe updates with rollback

Choose MainWP if:

You have 20+ sites
Data ownership matters to you
You're comfortable running another WordPress installation

Choose custom scripts if:

You're comfortable with the command line
You want zero ongoing cost
You have SSH access to client servers
You want maximum flexibility

Don't choose scripts if:

You're not comfortable debugging shell scripts
Your clients are on shared hosting without SSH
You want a visual dashboard without building one

The custom script option, ready-made

If the scripts approach sounds right but you don't want to spend 12 hours building them from scratch, I put the full toolkit together: bulk update script (Bash for Linux, PowerShell for Windows), security audit, uptime monitor, HTML report generator, and clients.json template.

WordPress Agency Automation Bundle -- 19 PLN, use DEVTO for 20% off.

What do you use for managing multiple WordPress sites? Curious whether the community has moved more toward cloud dashboards or self-hosted in recent years.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

WooCommerce maintenance: 8 checks that keep payment processing alive (with SQL queries)

devautomation — Wed, 20 May 2026 17:29:04 +0000

A WooCommerce store going down at 11pm on a Friday is a different emergency than a brochure site going down.

Missed orders are lost revenue. Failed payments are angry customers. A hacked checkout is a PCI incident.

After managing WooCommerce stores for multiple clients, I've narrowed the monthly maintenance down to 8 checks that prevent the most expensive problems. Each one has a real failure story behind it.

1. Test a real payment (every month, no exceptions)

The most common thing WooCommerce maintainers skip is actually testing checkout. They update plugins, check the dashboard, and assume everything works.

Checkout breaks in ways that look fine from the admin panel:

Payment gateway webhook URL changed (after migration or domain change)
SSL certificate expired on a subdomain used for payment callbacks
Plugin conflict that only surfaces at the payment step
Stripe API key rotated but not updated in WooCommerce settings

Monthly protocol:

Go through checkout as a real customer
Use the gateway's test mode (Stripe: use card 4242 4242 4242 4242)
Verify the order appears in WooCommerce -> Orders
Verify the customer receives a confirmation email

If any of these fail: you found a problem before your client did.

2. Hunt stuck pending orders

Pending orders that never complete are a silent revenue drain. A customer's bank approves the charge, something breaks in the callback, WooCommerce never marks it complete.

SELECT ID, post_status, post_date, post_modified 
FROM wp_posts 
WHERE post_type = 'shop_order' 
AND post_status = 'wc-pending' 
AND post_date < DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY post_date DESC;

More than a handful of these? Something is wrong with your payment gateway webhook. Check WooCommerce -> Status -> Logs for payment errors from the past 30 days.

3. Clean WooCommerce sessions before they eat your database

Active WooCommerce stores accumulate tens of thousands of abandoned sessions in wp_woocommerce_sessions. Each one is a database row. After a year, this table can be hundreds of megabytes.

This single query reclaims most of it:

DELETE FROM wp_woocommerce_sessions 
WHERE session_expiry < UNIX_TIMESTAMP();

Run it monthly. On a busy store, you'll see meaningful query performance improvement within a few days as the database cache stops fighting session bloat.

Follow with:

DELETE FROM wp_options 
WHERE option_name LIKE '_transient_wc_%' 
AND option_name NOT LIKE '_transient_timeout_wc_%';

4. Audit shop manager accounts

This one gets skipped because it feels administrative. It's not.

Go to Users -> filter by "Shop Manager" role. Review every account:

Is this still an active employee/contractor?
When did they last log in?
Do they need shop manager access or could editor work?

I found a former contractor with shop manager access 8 months after they stopped working with a client. They had full order visibility and could issue refunds.

Also check WooCommerce -> Settings -> Advanced -> REST API. Remove any API keys that aren't actively used.

5. Verify product stock integrity

WooCommerce can oversell if inventory management is misconfigured or if there's a plugin conflict. Negative stock happens more than you'd think.

SELECT posts.post_title, meta.meta_value as stock
FROM wp_posts posts
JOIN wp_postmeta meta ON posts.ID = meta.post_id
WHERE meta.meta_key = '_stock'
AND CAST(meta.meta_value AS SIGNED) < 0
AND posts.post_type = 'product';

Also check for:

Sale prices with expired end dates still active (WooCommerce sometimes doesn't clear these cleanly)
Products marked in-stock with stock management enabled but quantity set to 0
Variable product variations showing incorrect availability

6. Send a test email through every WooCommerce notification

Email delivery is the most common WooCommerce complaint clients bring up. "Customers say they're not getting order confirmations."

Default WordPress mail (wp_mail with no SMTP) fails silently on most hosting environments. Spam filters eat it. If you haven't set up SMTP, do it now -- it's a 15-minute fix that prevents weeks of support tickets.

Monthly check:

WooCommerce -> Settings -> Emails -- click "Send test email" on: New Order, Order Processing, Order Complete
Check spam folder for each
Verify the from address is your client's domain, not wordpress.com or the hosting platform

Test with mail-tester.com once a quarter -- it scores your deliverability and tells you exactly what to fix.

7. Check WooCommerce autoloaded data

Slow admin and slow frontend can both trace back to autoloaded options table bloat. WooCommerce adds to this.

SELECT option_name, LENGTH(option_value)/1024 as kb
FROM wp_options 
WHERE autoload = 'yes' 
AND option_name LIKE 'wc_%'
ORDER BY kb DESC 
LIMIT 10;

Anything over 100KB in a single option is worth investigating. Some plugins create massive autoloaded entries that load on every page request.

Total autoloaded data over 1MB will noticeably slow your site. Over 3MB, it's severe.

8. Review the fraud signals

Card testing fraud (bots testing stolen credit cards with small purchases) shows up as:

Unusual spike in failed transactions
Multiple orders from new accounts with different emails but similar patterns
Small value orders (under $5) that all fail

Check WooCommerce -> Status -> Logs for payment errors. A pattern of card_declined errors from different IPs in a short window is a card testing attack.

Countermeasures:

Enable Google reCAPTCHA on checkout (free, WooCommerce built-in)
Set minimum order amount if your products allow it
Your payment gateway (Stripe, PayU) has fraud rules -- check they're enabled

The checklist version

I turned these 8 checks plus about 50 more into a complete monthly WooCommerce maintenance checklist -- free download.

It covers updates, orders, payments, inventory, performance, security, email, compliance (GDPR), and backups, with the SQL queries and WP-CLI commands built in so you can move through it fast.

Free: WooCommerce Monthly Maintenance Checklist ->

If you manage multiple WooCommerce stores, the automation side -- running these checks across all sites automatically -- is covered in the WordPress Agency Automation Bundle ->

What's the WooCommerce issue you've spent the most time debugging? Payments, performance, or something else?

Managing WooCommerce stores commercially? The Agency Starter Kit has service agreement templates, proposal formats, and pricing calculators built for maintenance contracts.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

The WordPress maintenance business: real numbers, pricing math, and what most freelancers get wrong

devautomation — Wed, 20 May 2026 17:23:39 +0000

WordPress maintenance is one of the most reliably profitable niches in freelancing. It's also one of the most consistently underpriced.

After running maintenance contracts for years, here are the numbers and the mistakes I see most often.

The math that makes this business work

A typical WordPress maintenance client requires about 1.5-2.5 hours of actual work per month once you're set up:

Updates: 20-40 minutes (with proper tooling, much less)
Security review: 15-20 minutes
Backup verification: 10 minutes
Report writing: 15-20 minutes
Unexpected issues (averaged across all clients): 15-30 minutes

At a standard freelance rate of $50-80/hour, that's $75-200 of work.

Most freelancers charge $50-80/month.

The margin is uncomfortable. But that's before you account for automation.

What automation actually changes

I spent about 12 hours over one month building scripts that automate:

Updates across all client sites (SSH -> backup -> update -> test)
Security scanning
Monthly HTML report generation
Uptime monitoring with email alerts

Result: what was 1.5-2.5 hours per client is now 10-15 minutes of reviewing output that ran automatically.

On 10 clients: 15-25 hours/month -> 1.5-2.5 hours/month.

The hourly math at $75/month per client:

Before automation: $75 / 2 hours = $37.50/hour
After automation: $75 / 0.2 hours = $375/hour

Same work. Same client. Same invoice. Different leverage.

What most freelancers get wrong about pricing

Mistake 1: Pricing by what feels fair instead of what it costs

Calculate your actual floor:

Monthly overhead (software, tools, insurance, admin):    $200
Target monthly income:                                   $6,000
Billable hours available (realistic, not optimistic):    100

Minimum hourly rate = ($6,000 + $200) / 100 = $62/hour
Add 30% for taxes: $62 x 1.3 = $80/hour
Add 15% margin:    $80 x 1.15 = $92/hour

Most WordPress freelancers have never done this math. They price by feel, which means they price below their actual floor.

Mistake 2: Charging per site instead of per value

A WooCommerce store doing EUR50,000/month revenue and a portfolio site for a local photographer are both "one WordPress site." The maintenance work is roughly similar. The value to the client is not.

Tiered pricing by business type:

Portfolio / brochure site: $80-120/month
Small business with leads/bookings: $120-200/month
E-commerce / WooCommerce: $200-400/month
High-traffic or high-revenue sites: $400+/month

Mistake 3: Month-to-month only

Annual prepay discounts serve you more than the client. Offering 10-13% off for annual upfront:

Removes churn risk for 12 months
Gives you cash flow
Clients who prepay never cancel mid-year

On 10 clients at $150/month: $18,000 annual value. Offer 10% off: client saves $1,800, you get $16,200 upfront.

The churn problem no one talks about

The biggest threat to a maintenance business isn't finding clients -- it's keeping them.

Average monthly churn rate in subscription businesses: 3-8%.

At 5% churn: You lose half your client base in a year without adding anyone new.

What actually reduces churn:

Monthly reports -- clients who receive reports cancel less. They see the value. Clients who get no communication wonder if they're paying for anything.
Proactive communication -- tell them about the SSL expiry you caught before it expired, the plugin vulnerability you patched before anyone exploited it. These moments justify the retainer.
Reasonable response times -- most clients don't need 1-hour response. They need to know they won't be ignored.

How long to build a $3,000/month maintenance business

Working backwards:

$3,000/month / $150/average client = 20 clients
At 5% monthly churn: need ~1 new client/month just to maintain
Realistic acquisition rate (with consistent outreach): 1-2 new clients/month

Timeline: 12-18 months to reach 20 clients while managing churn.

Faster if:

You already have web design clients you can convert to maintenance
You run the systematic outreach (about 20 cold emails/month needed for 1 new client)
You raise prices as your client list fills (waitlist = clear signal to raise rates)

The stack that makes it work

Free or near-free tools:

WP-CLI -- command-line WordPress management (free)
UptimeRobot -- uptime monitoring, email alerts (free tier: 50 monitors)
Google Search Console -- SEO monitoring for clients (free)
UpdraftPlus -- backups (free tier sufficient for most sites)
Wordfence -- security scanning (free tier)

Paid but worth it:

ManageWP or MainWP -- centralized dashboard for all sites ($100-200/year for small agency)
WP Rocket -- caching/performance ($60/year/site -- pass through to client)
ShortPixel -- image optimization ($10-20/month for unlimited sites)

Monthly tool cost for 10 sites: roughly $50-80. On $1,500/month retainer income, that's a 5% overhead ratio.

What I've packaged up

The automation scripts I use (Bash for Linux servers, PowerShell for Windows management): WordPress Agency Automation Bundle ->

The business side -- service agreement, proposal templates, pricing calculator, 15 client email templates, 5-day onboarding checklist: WordPress Agency Starter Kit ->

Getting clients in the first place -- cold email sequences, LinkedIn scripts, discovery call guide: WordPress Client Acquisition Kit ->

What's the biggest challenge in your WordPress maintenance business right now -- finding clients, pricing, or keeping up with the work?

These numbers are from my own experience managing sites across various client types. Your market will differ -- adjust accordingly.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

WordPress site running slow? Here's the exact checklist I use to diagnose any site in 30 minutes

devautomation — Wed, 20 May 2026 17:02:05 +0000

Client calls. Their site is "just slow." No other details.

Here's the process I've refined over years of WordPress maintenance for diagnosing performance issues fast - from first look to prioritized action list in about 30 minutes.

Step 1: Baseline measurements (5 minutes)

Before touching anything, document where you're starting.

Run every test 3 times and average:

- Google PageSpeed Insights (mobile + desktop): pagespeed.web.dev
- GTmetrix: note TTFB, total page size, total requests
- Google Search Console: Core Web Vitals report (if you have access)

The numbers that matter most:

Metric	Target	What it affects
LCP	< 2.5s	Largest Contentful Paint - Google ranking
TTFB	< 800ms	Server response - often hosting problem
Page size	< 3MB	Bandwidth - especially mobile
Mobile score	> 70	Google uses mobile-first indexing

Write these down. You can't prove improvement without a baseline.

Step 2: Server response time tells you 80% of the story

TTFB (Time to First Byte) is the most revealing single metric.

# Quick TTFB check from command line
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com

Under 200ms: Server is fast, look elsewhere

200ms-800ms: Acceptable, worth improving

Over 800ms: Server or caching problem - fix this first before anything else

If TTFB is high, check:

PHP version - PHP 8.1+ is 2-3x faster than 7.4 for WordPress. Check in WP Admin ? Tools ? Site Health
Page cache - Is there any caching at all? Check response headers: curl -I https://example.com | grep -i cache
Hosting tier - Shared hosting with too many neighbors causes slow TTFB regardless of optimization

Step 3: Images are almost always the main culprit

Open GTmetrix ? Waterfall tab ? filter by "Image" ? sort by size.

Nine times out of ten, I find:

Hero images at 2-4MB (should be 100-300KB)
Images served at 3000px width but displayed at 800px
JPEG format instead of WebP (30-50% larger)
No lazy loading on below-fold images

Quick diagnosis:

// Run in browser console to find oversized images
document.querySelectorAll('img').forEach(img => {
    const rendered = img.getBoundingClientRect();
    const natural = { w: img.naturalWidth, h: img.naturalHeight };
    const waste = ((natural.w * natural.h) / (rendered.width * rendered.height)).toFixed(1);
    if (waste > 4) console.log(`Oversized: ${img.src.split('/').pop()} - ${waste}x larger than needed`);
});

Fix priority:

Compress existing images (ShortPixel, free tier = 100 images/month)
Enable WebP conversion going forward
Set explicit width/height on images (prevents layout shift)
Don't lazy-load above-fold images (hurts LCP)

Step 4: Caching check

Page caching is the single highest-impact fix for most WordPress sites.

Test if caching is active:

curl -I https://example.com | grep -i "x-cache\|cf-cache\|cache-control"

If you see X-Cache: HIT or CF-Cache-Status: HIT - caching is working.

If you see nothing or Cache-Control: no-cache - no page cache.

Without caching: Every visitor triggers PHP + database. 500ms-3s server time.

With caching: Pre-built HTML served directly. 50-200ms.

Best free options by hosting type:

Shared hosting (Apache): W3 Total Cache or WP Super Cache
LiteSpeed servers: LiteSpeed Cache (dramatically better than W3TC)
WP Engine / Kinsta / SiteGround: Built-in server cache - just make sure it's not disabled

Step 5: JavaScript bloat

Open Chrome DevTools ? Network ? filter JS ? reload ? sort by size.

Look for:

Files over 100KB (especially ones you don't recognize)
Scripts loading on pages where they're not needed (contact form plugin loading on every page)
Multiple jQuery versions (yes, this happens)

Find render-blocking scripts:
PageSpeed Insights ? "Eliminate render-blocking resources" ? shows you exactly which files.

Fix options:

Defer non-critical scripts: <script src="..." defer></script>
Use Asset CleanUp plugin to disable specific scripts on specific page types
Remove plugins you're not using (every plugin = more JS)

Step 6: Database audit

Runs slow even with caching? Look at the database.

Install Query Monitor plugin temporarily and load a few pages. Check:

- Queries tab: anything over 50ms is suspicious
- Number of queries: over 100 per page is high

Also check directly:

-- Autoloaded data (should be under 1MB)
SELECT SUM(LENGTH(option_value))/1024/1024 as mb 
FROM wp_options 
WHERE autoload = 'yes';

-- Post revisions (often thousands on active sites)
SELECT COUNT(*) FROM wp_posts 
WHERE post_type = 'revision';

Quick wins:

// Add to wp-config.php - limit revisions going forward
define('WP_POST_REVISIONS', 5);

Then use WP-Optimize to clean up existing bloat.

Step 7: The things people forget

Google Fonts: Every Google Fonts family = external DNS lookup + connection. For a site with 3 font families loaded from fonts.googleapis.com, that's 3 extra connections before the page can render.

Fix: Host fonts locally with the OMGF plugin. Free, 10-minute setup.

Font display: Text invisible while font loads? Add font-display: swap to @font-face declarations. Prevents invisible text from hurting LCP.

Third-party scripts: Chat widgets, analytics tags, social share buttons - each one adds DNS lookup + connection time. Audit them. Do you actually need all of them?

My 30-minute flow

0-5min:   Baseline measurements (PageSpeed + GTmetrix)
5-10min:  TTFB check ? hosting/caching decision
10-15min: Image audit via Waterfall
15-20min: Cache headers check + caching plugin status
20-25min: JS bloat + render-blocking resources
25-30min: Database quick check + fonts

Result: Prioritized list of fixes with estimated impact for each.

The report I send clients

After the audit, I send a one-page report: current scores, issues by priority (critical / important / nice-to-have), what I fixed, what I recommend, and projected improvement.

I've put together the full checklist, implementation guides, and the client report template in a kit:

WordPress Speed & Performance Audit Kit ? - use SPEED for 26% off.

Or just use the checklist above on your next slow site.

What's the most common performance issue you find on client WordPress sites? Drop it in the comments.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

How I land WordPress maintenance clients with cold email (real sequences, real results)

devautomation — Wed, 20 May 2026 16:55:02 +0000

Finding good maintenance clients is harder than doing the actual work.

I've been doing WordPress maintenance for several years. The technical side - updates, backups, security monitoring - I figured out quickly. But for the first two years I relied entirely on word of mouth, which meant my client list grew randomly and slowly.

Then I started treating client acquisition like a system. Here's exactly what I do.

The core insight

Most WordPress freelancers send generic "I do web maintenance" pitches. They get ignored.

The emails that get replies are specific. They reference the actual site, the actual problem, and demonstrate that you actually looked.

This takes 3-5 minutes per prospect. It's worth it.

Step 1: Find prospects with real problems

I don't cold email random businesses. I find ones with specific, verifiable issues.

How to find them:

# Check WordPress version from page source
curl -s https://example.com | grep 'ver=' | head -5

# Check SSL expiry
echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

# Quick uptime check
curl -o /dev/null -s -w "%{http_code}\n" https://example.com

For visual browsing, the Wappalyzer browser extension shows WordPress version and plugins on any site you visit. I use it while doing normal browsing - if I see a local business with an outdated stack, I note it down.

Where to look:

Google Maps search for local business types, then check their sites
Local business Facebook groups (look for people complaining about their site)
LinkedIn connections who run businesses

Step 2: The "I found something" email

The single best opener I've found is mentioning something specific I found on their site. Not "I do WordPress maintenance," but "your site is running WordPress 5.8 which has a known RCE vulnerability."

Here's the sequence I use:

Email 1 (Day 1):

Subject: [Business name] website - quick heads up

Hi [Name],

I was browsing local [business type] websites and noticed your site is running WordPress [VERSION] - a version with a known security vulnerability that's been actively exploited since [DATE].

I thought you'd want to know before it becomes a problem.

I do WordPress maintenance for local businesses. Happy to fix this and check for other issues at no charge as an introduction.

Interested?

[My name]

That's it. 4 sentences. No pitch, no service list, no "I have 10 years of experience."

Email 2 (Day 5, no reply):

Follow up once with more context about the risk. Still no pitch.

Email 3 (Day 12, no reply):

Final email. Acknowledge you're going to stop following up. Sometimes this one gets the reply when the others didn't.

Step 3: The "free audit" variation

For prospects where the issue isn't obvious from the outside, I offer a free mini-audit.

Subject: Free WordPress health check for [Business]

Hi [Name],

I ran a quick check on your website and found a few things worth your attention:

SSL certificate expires in 23 days

WordPress is 14 months out of date

Site loads in 7.2 seconds on mobile (Google recommends under 3)

I've put together a short report - no cost, no obligation. Want me to send it over?

The response rate to this is roughly double the cold issue email, but it takes more time upfront. For high-value targets it's worth it.

Step 4: Discovery call

When they reply, I do a 15-minute call. My goal isn't to pitch - it's to understand their situation and find out if I can genuinely help.

Questions that matter:

When was the site last updated?
Who handles it now? (Internal? Agency? Nobody?)
Has anything ever gone wrong?
How much time does the team spend dealing with site issues?

The last question usually ends the conversation. Nobody expects their answer to be "actually, we spend several hours a year on this." But they almost always do.

The numbers

From a typical month of outreach:

Activity	Volume	Result
Prospects researched	30	-
Cold emails sent	20	-
Replies	3-5	15-25% reply rate
Discovery calls	1-2	~50% of replies
New clients	0.5-1	~50% of calls

At $150/month per client (conservative), consistent monthly outreach adds $75-150/month recurring indefinitely. Over a year, 8-12 new clients = $1,200-1,800/month added to your retainer income.

What I learned from getting it wrong

For the first two years, my emails were terrible. Paragraphs about my background. Lists of services. "I specialize in..." language.

Nobody replied.

The shift was understanding that nobody hires a WordPress maintainer because they want WordPress maintenance. They hire one because their site broke, their site is slow, or they're worried it will break.

Lead with their problem, not your solution.

The toolkit I use

Wappalyzer - browser extension for instant tech stack detection
GTmetrix - free site speed analysis (generates shareable reports for prospects)
crt.sh - check SSL certificate expiry publicly
UptimeRobot free tier - monitor a few prospects to catch when they go down (great conversation starter)
Calendly free - scheduling link for discovery calls

Total cost: $0.

The templates

I've written out 5 complete email sequences (18 emails total) including the cold outreach variants, a referral request sequence, win-back campaigns, and a LinkedIn outreach system.

If you want to skip the writing: WordPress Client Acquisition Kit on Gumroad ? - use code DEVTO for 24% off.

What's your experience with cold outreach for freelance work? I'm curious whether the "specific problem" approach works in other niches the same way it does in WordPress.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com

I got tired of manual WordPress maintenance across 8 client sites - so I automated all of it

devautomation — Wed, 20 May 2026 16:53:50 +0000

If you manage WordPress sites for clients, you know the drill.

Every month, you log into each site, click "Update All Plugins," wait, check if anything broke, run a backup, scan for issues, repeat. For one site it's fine. For eight sites it's 6 hours of your life gone - every single month.

I finally got annoyed enough to fix this properly.

What manual WordPress maintenance actually costs

Here's the math I was doing before I automated:

8 client sites
~45 minutes per site (login, updates, backup verification, security check, client email)
= 6 hours/month
At $65/hour = $390/month of non-billable time

That's $4,680/year. For clicking update buttons.

The automation stack

I settled on two tools: WP-CLI (runs WordPress commands from the terminal) and SSH (connects to client servers remotely). Both are free, both are standard.

The workflow per site:

SSH into client server
Database backup (before touching anything)
wp core update
wp plugin update --all
wp theme update --all
Security audit
Generate HTML report

Here's a simplified version of the core script:

`ash

!/bin/bash

WP_PATH="/var/www/html/client-site"
BACKUP_DIR="/backups"
TIMESTAMP=$(date +"%Y-%m-%d_%H-%M")

1. Backup first

mkdir -p ""
wp --path="" --allow-root db export \
"/db_backup_.sql"

2. Update everything

wp --path="" --allow-root core update
wp --path="" --allow-root plugin update --all
wp --path="" --allow-root theme update --all

3. Flush cache

wp --path="" --allow-root cache flush
`

Simple. But the real value is running this across all client sites from a single config file.

The config approach

I keep a clients.json file:

json { "clients": [ { "name": "Client A Ltd", "slug": "client_a", "ssh_host": "server.clienta.com", "ssh_user": "root", "ssh_key": "~/.ssh/id_rsa_clienta", "wp_path": "/var/www/html/clienta", "active": true } ] }

One command runs maintenance across every active client. Add a new client - edit one JSON file.

The security audit

After updates, the script checks:

`ash

Check for exposed debug.log

if [ -f "/wp-content/debug.log" ]; then
echo "WARNING: debug.log exists - may contain sensitive data"
fi

Check wp-config.php permissions

CONFIG_PERMS=$(stat -c "%a" "/wp-config.php")
if [[ ! "" =~ ^(400|440|600|640)$ ]]; then
echo "WARNING: wp-config.php permissions: (should be 600)"
fi

World-writable PHP files

WRITABLE=$(find "" -name "*.php" -perm /o+w 2>/dev/null | wc -l)
if [ "" -gt 0 ]; then
echo "WARNING: world-writable PHP files found"
fi
`

Each client gets flagged items in their report.

The HTML report

The script generates a per-client HTML report:

? WordPress 6.5.3 - up to date ? 12 plugins updated ? Database backup: 45 MB ? Security scan: clean ? wp-config.php permissions: 644 (should be 600)

I email this to clients monthly. It shows them the value of what I'm doing.

The uptime monitor

Separate script, runs every 10 minutes via cron:

`ash

!/bin/bash

SITES=("https://client1.com" "https://client2.com")
ALERT_EMAIL="you@yourcompany.com"

for SITE in "${SITES[@]}"; do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 15 "")
if [ "" != "200" ]; then
echo "DOWN: (HTTP )" | mail -s "SITE DOWN: " ""
fi
done
`

Results

After running this for 6 months:

Monthly maintenance time: 6 hours ? ~20 minutes
Zero missed updates
Caught 2 sites with world-writable PHP files
One client site went down at 3am - got the alert, fixed it before they noticed

The full toolkit

I packaged everything - the bulk update script (Bash + PowerShell), security audit, uptime monitor, clients.json template, HTML report template, and maintenance checklist.

WordPress Agency Automation Bundle - use code DEVTO for 20% off.

Or use the snippets above as a starting point. Either way, stop clicking "Update All" manually eight times a month.

Questions about the implementation? Drop them in the comments.

More in this series: WordPress Agency Toolkit

All tools and templates: devautomation.gumroad.com