Almost every failed WordPress connection comes down to one of three things: a firewall in front of your site, your server stripping the login header, or the REST API being turned off. This guide walks through each.
First: which connection method are you using?
SnowSEO can connect to WordPress two ways.
Method | How it works | Best when |
Plugin | You install the SnowSEO plugin and paste a key generated in the dashboard. | Managed hosting, or anywhere a security plugin or firewall is in play. This is the more robust option. |
Application Password | You give SnowSEO your site URL, WordPress username, and an Application Password. | Simple setups where you would rather not install anything. |
If the Application Password method keeps failing, switch to the Plugin method. It avoids the two most common causes of failure entirely, because the plugin authenticates with its own key instead of relying on the Authorization header surviving the trip.
Firewall and security plugin blocks
This is the most common cause. Your site is up, your credentials are correct, but a firewall between SnowSEO and WordPress is rejecting the request before WordPress ever sees it.
Do not use IP allowlists. SnowSEO's outbound IP address is not stable and can change without notice. Worse, if your site is behind Cloudflare, your firewall logs will often show one of Cloudflare's own edge IPs rather than ours, so an IP rule would be both fragile and meaningless.
Allow by User-Agent instead. Every request SnowSEO makes carries a User-Agent containing SnowSEO, which never changes.
Cloudflare
Open your Cloudflare dashboard and select the domain.
Go to Security -> WAF -> Custom rules and click Create rule.
Name it something like "Allow SnowSEO".
Set the expression to match where URI Path contains /wp-json/ and User Agent contains SnowSEO.
Set the action to Skip, and tick the security features to skip, including WAF Managed Rules, Rate Limiting, and Browser Integrity Check.
Deploy the rule, then retry the connection in SnowSEO.
Also worth checking in Cloudflare:
SSL/TLS mode. If you use the Cloudflare proxy, set the mode to Full or Full (strict). Flexible mode causes redirect loops on REST requests.
Bot Fight Mode. This blocks non-browser traffic aggressively. If it is on, your Skip rule must come before it, or turn it off while you connect.
Under Attack mode. This blocks all API access. Turn it off to connect.
Wordfence
Wordfence can silently reject the login without telling WordPress why. Either:
Add a firewall rule allowing requests where the User-Agent contains SnowSEO, or
Put Wordfence into Learning Mode, run the connection, then switch it back to Enabled and Protecting.
Also check Wordfence's Rate Limiting and its "Block requests for non-existent users" option, both of which can interfere.
StackProtect and StackPath
Common on managed WordPress hosting. Add a WAF rule allowing requests where the User-Agent contains SnowSEO for the path /wp-json/snowseo/*. If your host manages the WAF for you, ask their support to add that rule.
Other security plugins
Sucuri, iThemes / SolidWP Security, All In One WP Security, NinjaFirewall, and Cleantalk can all block REST requests. Look for a setting like "Disable REST API", "Block unauthenticated REST API", or "XML-RPC and REST hardening" and add an exception, or disable it temporarily to confirm the cause.
Host-level firewalls
SiteGround, Kinsta, WP Engine, Hostinger, GoDaddy, and Cloudways all run their own WAF in front of your site, separate from anything you installed. If you have ruled out Cloudflare and your plugins, open a ticket with your host and ask them to allow requests with a User-Agent containing SnowSEO to /wp-json/. Most will do this in minutes.
"Your server is stripping the Authorization header"
If you see this message, WordPress never received your login. Some servers, particularly Apache running PHP as CGI or FastCGI, drop the Authorization header before PHP can read it.
Fix 1: use the Plugin method. The plugin does not depend on this header at all, so this problem disappears.
Fix 2: pass the header through. On Apache, add this to the top of your .htaccess, above the WordPress block:
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
Or, if your host prefers it:
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
On nginx with PHP-FPM, add fastcgi_pass_header Authorization; to the PHP location block.
If you are not comfortable editing server config, send your host this line: "please make sure the HTTP Authorization header is passed through to PHP." They will know what to do.
REST API not found or disabled
Open https://yoursite.com/wp-json/ in a browser while logged out. You should see a wall of JSON.
A 404 page means the REST API is unreachable. Go to Settings -> Permalinks in WordPress and click Save, without changing anything. This regenerates the rewrite rules and fixes it surprisingly often.
A "REST API disabled" message means a plugin turned it off. "Disable REST API", many security plugins, and some optimisation plugins do this. Add an exception or disable that plugin.
An HTML page rather than JSON usually means a firewall or a caching layer intercepted the request. See the firewall section above.
A 403 points at a security plugin or host WAF.
SnowSEO automatically retries with the alternative ?rest_route= style URL when the pretty /wp-json/ path fails, so if pretty permalinks are the only problem, the connection often still succeeds.
Application Password errors
Message | What to do |
That WordPress username wasn't found | Use your actual WordPress login username from Users -> Profile, not the name you gave the Application Password, and not your email address. |
The application password is invalid or has been revoked | Generate a fresh one under Users -> Profile -> Application Passwords and paste it again. Copy it exactly as shown, spaces included. |
Application Passwords are disabled on this site | A plugin or a filter in your theme has disabled the feature. Re-enable it, or use the Plugin method instead. |
Application Passwords are disabled for this user | Enable them for that account, or connect with an administrator account that has them enabled. |
Access forbidden | A security plugin or firewall is blocking the REST API. See the firewall section above. |
Two more things to check:
Application Passwords require HTTPS. WordPress hides the feature entirely on sites served over plain http.
Use an account that can publish. An Administrator or Editor role. Author and Contributor accounts cannot do everything SnowSEO needs.
Site URL problems
Enter the exact URL your site actually serves, including www if you use it. SnowSEO follows redirects to find the canonical origin, but starting from the right one is safer.
Use https, not http.
If WordPress lives in a subfolder, include it, for example https://example.com/blog.
A site behind HTTP Basic Auth, on a staging password wall, or on a private network cannot be reached by SnowSEO at all.
Connected, but publishing does not work
Posts appear as drafts. Check the publishing settings for the integration, and confirm the connected user has permission to publish rather than just to create.
The post published but does not appear on the site. Clear your caching layer. WP Rocket, LiteSpeed Cache, W3 Total Cache, and your host's own page cache all serve stale pages after an API write.
Images are missing. The media upload endpoint may be blocked separately from the posts endpoint, or your PHP upload size limit may be too small.
It worked and then stopped. The Application Password was probably revoked, or a security plugin updated and reset its rules. Reconnect and re-check your firewall rule.
Still stuck?
Email [email protected] with:
Your site URL and which connection method you tried
The exact error message SnowSEO showed
Your host, and whether you use Cloudflare or a security plugin
What https://yoursite.com/wp-json/ returns in a logged-out browser
For initial setup instructions, see How to integrate CMS and auto-publish blog posts.