When CoSchedule can't reach your WordPress site, posts stop syncing, the site disconnects, or social messages for a post fail. Most of these problems come from settings on your site: its security tools, other plugins, server or timezone. Work through the steps below in order, and test after each one. This applies to every plan.
Before you start
- You need admin access to your WordPress site.
- Steps 4 to 8 may need whoever manages your site's hosting, security or CDN. CoSchedule can't change your site's settings for you.
- Write down the exact error and when it happened. You'll need them if you contact support.
Find your problem
What you see | Start at |
|---|---|
The site won't connect, or connects and then disconnects | Step 1 |
A warning that your plugin is out of date | Step 2 |
An error that you may have connected this site to a different calendar | Step 3 |
An error about your WordPress categories, authors or plugin list | Step 3 |
The CoSchedule plugin isn't active, or isn't connected to this calendar anymore | Step 3 |
An error names a plugin that conflicts with CoSchedule | Step 4 |
The problem started after you installed or updated another plugin | Step 4 |
Your site couldn't find /wp-admin/admin-ajax.php, or sent CoSchedule to the WordPress sign-in page | Step 4 |
Your site sent back an empty response, or not the reply CoSchedule expects | Step 4 |
Cloudflare showed CoSchedule a bot check, or a Cloudflare rule or Cloudflare Access blocked it | Step 5 |
A firewall, security plugin or your host's bot protection blocked CoSchedule | Step 5 |
WordPress.com, your site or your host limited how often CoSchedule can reach your site | Step 5 |
Could not reach WordPress admin, your site requires HTTP Basic Auth credentials, or your server asks for a username and password | Step 6 |
Social messages for a post fail with Scheduled too far in the past, or posts publish at the wrong time | Step 7 |
Problem with your server's timestamp, or your site's web server sent an empty universal timestamp or one that was a bit off | Step 7 |
Your site's server returned an error, or didn't respond within 20 seconds | Step 8 |
Your site can't connect to its database | Step 8 |
CoSchedule can't find your site's domain, couldn't open a secure connection, or the server closed the connection | Step 8 |
If an error appears when you move a post on the calendar
When your WordPress site doesn't accept a change, CoSchedule shows WordPress didn't confirm the update, the cause and a How to fix this link. Find the cause in the table above.
If the message says your site didn't respond within 20 seconds or sent back an empty response, the change may have saved. Refresh the page and check the post's date before you move it again.
Step 1: Check the basics
- Do a hard refresh: Cmd+Shift+R on Mac, or Ctrl+F5 on Windows.
- Try again in a private window or another browser.
- Check status.coschedule.com for a current incident.
Step 2: Update the plugin
The current version of the CoSchedule plugin is 3.4.2.
- In your WordPress admin, open the Plugins screen.
- Find CoSchedule and check its version.
- If it's older than 3.4.2, update it.
WordPress may say the plugin hasn't been tested with your version of WordPress. You can ignore that notice. If the update fails, see Update or reinstall the CoSchedule WordPress plugin.
Step 3: Refresh and reset the connection
Refresh the connection first:
- In CoSchedule, go to Settings > Integrations > WordPress.
- Click Manage Site for the site.
- Click Refresh Connection.
- Check that the WordPress URL under Connection Details is your live site.
If the problem continues, reset the plugin:
- In your WordPress Plugins screen, deactivate CoSchedule.
- Activate CoSchedule again.
- When the CoSchedule sign-in opens, sign in with your CoSchedule account. If no sign-in window opens, allow pop-ups for your site in your browser.
If you can see your calendar and posts, the site is connected.
Deactivate the plugin; don't delete it. Don't disconnect the site in CoSchedule to troubleshoot, either. Disconnecting removes the site's scheduled posts from your calendar, along with their social messages and social analytics.
If CoSchedule says you may have connected this site to a different calendar, the site is still connected to another calendar, often through a staging copy. Disconnect it from that other calendar, then connect again. See Connect WordPress to CoSchedule.
If you have a staging or development copy of your site, deactivate the CoSchedule plugin on that copy. A connected copy creates duplicate projects on your calendar.
Step 4: Check for plugin conflicts
Another plugin on your site can stop CoSchedule from connecting or syncing. Check the known conflicts first, then test your other plugins.
Check for known conflicts
If your site uses one of these plugins, do what the table says:
Plugin | What to do |
|---|---|
Disable XML-RPC Pingback | Deactivate it. |
Easy PayPal Custom Fields | Deactivate it. |
Easy WP SEO | Switch to a different SEO plugin, such as Yoast SEO. |
Indeed Ultimate Affiliate Pro | Deactivate it. |
PilotPress | Deactivate it. |
Polylang | Contact support. |
Redirection | Deactivate it. |
Role Scoper | Switch to a different role plugin. Role Scoper is no longer developed. |
Root Relative URLs | Deactivate it. |
W3 Total Cache | Contact support. |
WishList Member | Deactivate it. |
WordPress Tweet Button | Deactivate it. |
WP-SpamShield | Turn on the Static IP Proxy (Step 5), then allow its address in WP-SpamShield. |
Wordfence and Solid Security are covered in Step 5. For every known conflict, including ones that don't affect the connection, see Fix WordPress plugin conflicts.
Find a conflicting plugin
If none of those plugins is on your site, test your other plugins. Your site admin can do this without affecting visitors:
- Install the Health Check & Troubleshooting plugin.
- Turn on its troubleshooting mode. Your other plugins turn off for your account only.
- Test CoSchedule. If the problem is gone, a plugin is the cause.
- Turn your other plugins back on one at a time, and test CoSchedule after each.
- When the problem comes back, the plugin you just turned on is the cause.
- Look it up in Fix WordPress plugin conflicts. If it isn't listed, contact support with the plugin's name and a screen recording of the problem.
Errors caused by a plugin
- Plugins that hide or rename wp-admin: CoSchedule says your site couldn't find /wp-admin/admin-ajax.php. Set the plugin to leave /wp-admin/admin-ajax.php at its usual address.
- Private-site or forced sign-in plugins: CoSchedule says your site sent it to the WordPress sign-in page. Set the plugin to allow /wp-admin/admin-ajax.php without a sign-in.
- If CoSchedule says your site sent back an empty response, another plugin usually stopped the request after WordPress saved the change. Your server's PHP error log names that plugin. Your host can find the log for you.
Step 5: Let CoScheduleBot through your security tools
CoSchedule syncs with WordPress through CoScheduleBot, its web crawler. Security plugins, firewalls, hosting security services and CDNs can block it. Ask whoever manages your site's security to allow these in every one of those tools:
- Requests whose user agent contains CoScheduleBot.
- 34.202.82.63, the address CoSchedule uses for WordPress syncing and link previews.
- 52.71.109.154, the address of CoSchedule's Static IP Proxy.
Allowing the IP addresses alone is often not enough. Bot protection rules usually block CoScheduleBot whatever address it comes from, so they need to let its user agent through too.
- Cloudflare: add a rule that lets requests whose user agent contains CoScheduleBot skip security checks, and turn off Bot Fight Mode. A skip rule doesn't get past Bot Fight Mode.
- Cloudflare rate limiting: if a rule blocks CoSchedule with Cloudflare error 1015, exclude CoScheduleBot's IP addresses from that rule.
- Cloudflare Access: add a Bypass policy for /wp-admin/admin-ajax.php, so CoSchedule doesn't have to sign in.
- SiteGround: ask SiteGround support to let CoScheduleBot past its bot protection.
- WordPress.com: if WordPress.com limits how often CoSchedule can reach your site, wait a few minutes and try again. If it keeps happening, ask WordPress.com support to allow CoScheduleBot.
- Wordfence: allow CoScheduleBot and its IP addresses. If that doesn't work, deactivate Wordfence.
- Solid Security: turn off its filter for suspicious query strings.
Some security setups, such as WP-SpamShield, need CoSchedule to reach your site from one fixed address. Turn on the Static IP Proxy:
- Go to Settings > Integrations > WordPress.
- Click Manage Site for the site.
- Under Static IP Proxy, click Enable.
- Add the proxy address CoSchedule shows to your firewall's allow list.
Copy this note and send it to your host or IT team:
Please allow CoSchedule's crawler, CoScheduleBot, to reach our WordPress site. Allow requests whose user agent contains "CoScheduleBot", and allow the IP addresses 34.202.82.63 and 52.71.109.154. If a firewall or bot protection service blocks these requests, add a rule that lets them through. Details: https://coschedule.com/support/social-publishing/links/what-coschedulebot-is
Step 6: Add your HTTP auth details
Do this step if CoSchedule says Could not reach WordPress admin, that your site requires HTTP Basic Auth credentials, or that your server asks for a username and password. All three mean your server asks for basic HTTP authentication before anyone reaches WordPress.
- Go to Settings > Integrations > WordPress.
- Click Manage Site for the site.
- Under WordPress Basic HTTP Auth, click Enable.
- Enter your server's HTTP auth username and password.
- Click Save.
Use the HTTP auth details your host or server admin set up, not your WordPress login.
Step 7: Match your timezones and server time
WordPress posts publish on your site's timezone. Social messages, including the ones that promote a post, follow your calendar's timezone. When the two differ, messages can fail with Scheduled too far in the past.
- In WordPress, set your site's timezone to a city in your timezone, not a UTC offset.
- In CoSchedule, check your calendar's timezone under Settings > Configuration.
- Go to Settings > Integrations > WordPress.
- Click Manage Site for the site.
- Click Refresh Connection.
Reschedule any social messages that already failed. See Reschedule a social message.
If CoSchedule says Problem with your server's timestamp, or that your site's web server sent an empty universal timestamp or one that was a bit off, your server's time settings are wrong. It can't be fixed in CoSchedule or WordPress. Ask your host or web developer to turn on network time syncing (NTP) on the server and set PHP's date.timezone setting. See Fix WordPress timezone and timestamp problems.
Step 8: Check that your site and server respond
These errors mean CoSchedule couldn't get an answer from your site's server. Open your site in a browser first. If it doesn't load, contact your host. If it loads, find the message CoSchedule showed:
What CoSchedule says | What to do |
|---|---|
Your site's server returned an error | Ask your host to check the server's error log. |
Your site didn't respond within 20 seconds | Refresh the page to check whether the change saved. If it keeps happening, ask your host why your site responds slowly. |
Your site can't connect to its database | Ask your host to get the database back online. |
CoSchedule can't find your site's domain | If you moved your site to a new domain, refresh the connection and check the WordPress URL, as in Step 3. |
Your site's server closed the connection | Check that your site is online. If you moved hosts, make sure your domain points to the new server. |
CoSchedule couldn't open a secure connection | Ask your host to check that your site's SSL certificate is installed and hasn't expired. |
Still not working?
Contact support and include:
- Your site's URL.
- The exact error, or a screenshot of the whole browser window.
- When it happened, with your timezone.
- The browser you used.
- Which steps above you tried, and what happened after each.
- Any security plugin, firewall or CDN your site uses.
See Contact support and find CoSchedule policies.