Troubleshooting

Agent Can’t Log Into WordPress?

Use the WordPress REST API path instead of browser login so your agent can draft and publish posts reliably.

Community pattern: users ask the agent to "log into WordPress and post" and hit browser-related failures. The fix is usually simple: switch from browser automation expectations to API-based publishing.

Important: most heyron/OpenClaw agents do not have a full visual browser automation stack by default. They can read, write, call APIs, and run tools. For WordPress, API is the reliable lane.

Fast path (4 steps)

1) Confirm your site supports WordPress REST API

Most modern WordPress installs do. Check this URL in your browser:

https://YOUR-SITE.com/wp-json/

If you get JSON output, API is available.

2) Create an Application Password in WordPress

In WordPress admin, go to Users → Profile → Application Passwords. Create one for your agent workflow and copy it once.

3) Give your agent only what it needs

Site base URL
WordPress username
Application Password (not your main account password)
Exact task, like "create draft" vs "publish now"

4) Run a tiny draft canary first

Ask your agent to create one draft post titled:

WP_API_CANARY_{{today}}

If that works, then scale to full workflows.

Prompt you can paste to your agent

I need you to publish to WordPress using REST API (not browser automation). Site URL: https://YOUR-SITE.com Username: YOUR_WP_USERNAME Application Password: YOUR_APP_PASSWORD Task: 1) Create one DRAFT post titled "WP_API_CANARY_TEST" 2) Return the post ID + edit URL 3) Do not publish yet 4) If blocked, return exact HTTP status and response body

Common errors and what they mean

401 Unauthorized: username/app password mismatch, or security plugin blocking API auth.
403 Forbidden: account lacks capability to create posts, or host/plugin policy blocks endpoint.
404 on /wp-json/wp/v2/posts: permalink or REST route issues, sometimes caused by hardening plugins.
Agent says "browser problem": expected behavior when prompt asks for visual login instead of API calls.

Advanced edge cases (high-friction but common)

Cloudflare/WAF challenge pages (HTML instead of JSON): your agent is hitting a bot challenge. Allowlist /wp-json/* for API traffic or relax the rule for authenticated requests.
"Application Passwords" section missing: some security policies/plugins disable it. Re-enable application passwords or use a dedicated plugin-based token flow.
2FA enabled on the account: app passwords usually bypass interactive 2FA prompts, but some plugins break this. Test with a fresh dedicated automation user.
Wrong site in multisite setups: credentials may auth successfully but post to the wrong blog/site context. Verify returned link host + path before publishing.
Content created but formatting looks broken: send HTML content explicitly and set status: draft first. Validate rendering in WordPress editor before publish.

Known-good recovery prompt (copy/paste)

Do NOT use browser automation. Use WordPress REST API only. Goal: create exactly one draft post and return proof. Connection details: - Site: https://YOUR-SITE.com - Username: YOUR_WP_USERNAME - Application Password: YOUR_APP_PASSWORD Required sequence: 1) GET /wp-json/ and confirm JSON (return first 200 chars) 2) POST /wp-json/wp/v2/posts with: - title: "WP_API_CANARY_TEST" - status: "draft" - content: "API canary" 3) Return ONLY: - HTTP status - post id - edit link - public link 4) If failure, return exact status + raw response body. Do not paraphrase.

Security guardrails (use these)

Use an Application Password, never your main WordPress login password.
Prefer a dedicated low-privilege editor account for automation tasks.
Start with draft-only mode until output quality is stable.
Have the agent return post ID + permalink proof after each write.

Don’t do this: "Here are my admin creds, go click around and post anything." That creates security risk and unreliable behavior at the same time.

When to escalate to support

If your canary draft fails, share this exact packet:

Site URL (redact private subpaths if needed)
Exact endpoint attempted (for example /wp-json/wp/v2/posts)
HTTP status code + response body
Whether /wp-json/ loads in browser
Whether security plugins/WAF are enabled

Bottom line: for WordPress, treat your agent like an API operator, not a browser clicker. API + canary draft + proof output is the highest-reliability pattern.