We manage 159 personal brand websites through BlitzAdmin. Each one runs WordPress with Rank Math SEO, Elementor, and our Content Factory pipeline. When we built the automation system to run weekly fleet audits and daily content publishing across all 159 sites, we hit a wall that most agencies will eventually face: the WordPress REST API won’t let you write anything with a regular password.
This article explains what Application Passwords are, why they matter for automation at scale, and how we’re rolling them out across every site in our fleet.
The authentication problem nobody warns you about
WordPress has a full REST API that can do everything the admin dashboard does — create posts, update pages, manage media, check settings, configure SEO. It’s how our Claude AI agents publish content and run audits without ever opening a browser.
But here’s the catch: the REST API requires Application Passwords for external authentication. Your regular WordPress login password — the one you type into wp-admin — does not work with Basic Auth over the API. WordPress made this decision deliberately. Your admin password is too powerful to send over API calls, so they created a separate credential system specifically for programmatic access.
🔑 The Master Key vs. The Badge
Your admin password is the master key to the building. An Application Password is a badge that only opens specific doors. If the badge gets compromised, you revoke it without changing the master key. If the master key gets compromised, everything is exposed.
What Application Passwords actually are
Application Passwords were built into WordPress core starting in version 5.6. They are separate credentials tied to a specific user account that allow API authentication via Basic Auth over HTTPS. Each one gets a name (like “BlitzMetrics Automation”) so you know what it is for, and you can revoke any individual password without affecting your normal login or other app passwords.
✓ They never expire
Unlike JWT tokens (24-hour expiry) or session cookies, Application Passwords persist until you explicitly delete them. Your automation keeps running without re-authentication.
✓ Scoped to a user
The app password inherits the user’s role and capabilities. Administrator gets full access. Editor gets editor-level access. Clean separation.
✓ Independently revocable
If one integration gets compromised, kill that app password. Your login still works. Your other integrations still work. Nothing else breaks.
✓ Simple Basic Auth
No OAuth dance, no token refresh endpoints, no complex handshake. Just a simple Authorization header in every API request over HTTPS.
Why this matters for managing a fleet of WordPress sites
When you are running 10 or more WordPress sites for clients, manual management does not scale. Here is what our automation does that requires API write access:
PUBLISH
Blog posts — The Content Factory processes video transcripts into SEO-optimized articles and publishes them via the API with proper categories, tags, and Rank Math metadata.
UPDATE
Page content — When audit findings show missing or broken content, the agent fixes it directly.
UPLOAD
Media — Featured images need to be uploaded and attached to posts programmatically.
CONFIG
SEO settings — Rank Math settings, meta descriptions, and schema markup need API access to update at scale.
STAGE
Draft posts — Content staged for review sits as drafts until approved, all created via API.
Without Application Passwords, none of this works. You would need a human to log into each site’s wp-admin, navigate to the right page, and make changes manually. At 159 sites, that is a full-time job just to keep up with basic maintenance.
The security architecture we use
We store Application Passwords in a local credential cache on a secured machine — never in the cloud, never in a shared document, never in a Git repository. The cache file contains the domain, username, and Application Password for each site. The automation agents read from this cache when they need to make API calls.
1
HTTPS everywhere
Every API call goes over TLS. Application Passwords should never be sent over plain HTTP. WordPress enforces this by default on most hosts.
Every API call goes over TLS. Application Passwords should never be sent over plain HTTP. WordPress enforces this by default on most hosts.
2
Local-only storage
The credential cache lives on a single machine. Not synced to Dropbox, Google Drive, or any cloud storage. If the machine is compromised, we revoke all app passwords and regenerate.
The credential cache lives on a single machine. Not synced to Dropbox, Google Drive, or any cloud storage. If the machine is compromised, we revoke all app passwords and regenerate.
3
Named passwords with audit trail
Every Application Password is named “BlitzMetrics Automation” so you can see exactly which integrations have access. WordPress logs the last used date for each app password.
Every Application Password is named “BlitzMetrics Automation” so you can see exactly which integrations have access. WordPress logs the last used date for each app password.
4
WAF protection on admin endpoints
Most sites are behind Cloudflare or hosting-level firewalls that block programmatic access to wp-login.php and wp-admin. Even if someone steals the app password, they can only use it via the REST API, not to log into the dashboard.
Most sites are behind Cloudflare or hosting-level firewalls that block programmatic access to wp-login.php and wp-admin. Even if someone steals the app password, they can only use it via the REST API, not to log into the dashboard.
How we are rolling this out across 159 sites
Creating Application Passwords requires admin-level access to each site. Because of the WAF protection on most of our sites, we cannot do this with a simple script — the admin endpoints only accept real browser sessions. So we built a scheduled task that uses browser automation to work through the fleet systematically.
Rollout Process (per site)
1
Log into wp-admin via the browser (passes Cloudflare bot detection)
2
Navigate to user profile → Application Passwords section
3
Create new password named “BlitzMetrics Automation”
4
Save to local credential cache
✓
Verify write access with a test API call
The task processes about 20 sites per run and repeats until the full fleet is covered. Once a site has an app password, it never needs this process again — the password persists indefinitely.
What you should do if you manage WordPress sites
If you are managing more than a handful of WordPress sites and you want any kind of automation — even just posting content via the API — you need Application Passwords. Here is the minimum setup:
This is the plumbing that makes the Content Factory run at scale. Without it, you are stuck logging into wp-admin one site at a time, which means you are stuck being a VA instead of an architect.
Dennis Yu
Dennis Yu is the CEO of Local Service Spotlight, a platform that amplifies the reputations of contractors and local service businesses using the Content Factory process. He is a former search engine engineer who has spent a billion dollars on Google and Facebook ads for Nike, Quiznos, Ashley Furniture, Red Bull, State Farm, and other brands.
Dennis has achieved 25% of his goal of creating a million digital marketing jobs by partnering with universities, professional organizations, and agencies. Through Local Service Spotlight, he teaches the Dollar a Day strategy and Content Factory training to help local service businesses enhance their existing local reputation and make the phone ring.
Dennis coaches young adult agency owners serving plumbers, AC technicians, landscapers, roofers, electricians, and believes there should be a standard in measuring local marketing efforts, much like doctors and plumbers must be certified.