Your WP Server Cache Might Be Costing You Leads

Over the past 3 months I’ve been battling an infuriating and troubling issue. Some of my WordPress site’s forms were not submitting! But not all the time, just some of the time. A developer’s worst nightmare. This was having a real impact on lead generation efforts as this was most frequently occurring on downloadable PDFs or “lead magnets” where people can exchange an email address for a piece of premium content. Check out our offers and downloads page for some examples. I first discovered this issue after looking in my Google Analytics and spotting people hitting the same offer download page 5+ times in a single day. Since these pages receive relatively low traffic, it’s rare for them to get more than 1 hit per day. Seeing analytics data with that many hits points to someone refreshing the page repeatedly, probably out of frustration. In this post, I’ll dive into what the findings were of my investigation there, what the fix was, and raise awareness on a caching issue that’s probably costing businesses a lot of potential inbound leads from their contact forms.

Cryptic 403 Error On Form Submits In WordPress

So the specific page that kicked all this off was our MSP Industry Keywords Download, a list of 30 keywords with documented conversion history on paid search advertising efforts. This page is on a WordPress website and uses Beaver Builder subscribe forms to capture email addresses in exchange for the download. Eventually, I discovered the page was returning a 403 error on submit but it took a little while to get there.

The first time I investigated this issue I was unable to identify anything because I was signed in when troubleshooting. When you are signed in to the backend of WordPress most hosting providers will configure rules to bypass the cache when you’re viewing pages that are in edit mode. Therefore the page looked normal to me. I know that sometimes behavior can be different between signed-in and signed out so I also tested with a signed-out view, but was unable to replicate it because I had been re-publishing the page during troubleshooting. Re-publishing a page triggers a cache refresh, which will be important in a moment. I figured my analytics anomaly was maybe just a strange bot and let the issue go for the time being.

The Kindness of Strangers Helps Identify 403 On AJAX Call In WordPress

Not long after this initial troubleshooting session I had a kind stranger reach out to me, Sean from Crown Computers who said they had tried to download the lead magnet, but were unable to and also had a few questions about SEO for their MSP. I immediately opened up the browser and tried again only to discover that the form was getting stuck in a processing state and never actually submitting. When I inspected the Chrome Developer tools a 403 forbidden error was showing on admin-ajax.php. AHA! Now I had a trail to bloodhound down.

Troubleshooting the 403 Error On WordPress

An HTTP 403 error on WordPress means “forbidden”, the server is rejecting the call for a security reason. It’s a bit ambiguous, but happens often enough that there are a few blogs out there on the subject.

• WP Beginner Guide To Troubleshooting 403s
• Kinsta 403 Troubleshooting Guide
• Dreamhost 403 Troubleshooting Guide

Most of these blogs recommend the following potential culprits:

• Security plugins blocking AJAX calls
• File permission settings on your host
• Corrupt HTACCESS files
• VPNs or user PC-specific issues

None of these worked! I spoke to Beaver Builder (page builder vendor), Antispam Bee (security plugin vendor), Kinsta (my hosting provider), and Active Campaign (CRM vendor that the subscribe form is integrated with) all of whom were very helpful, but unable to help me figure out what was happening. They recommended doing some standard WordPress troubleshooting steps like disabling plugins and clearing your cache, which I did. I noticed that when I cleared my cache, this time around the issue went away and I was unable to reproduce it. I had to abandon collaboration with vendors, even a GitHub ticket trying to figure out what was going on. The issue just magically went away and I couldn’t bring it back. Maddening!

3rd Time The Charm For Identifying Cause Of 403 Error On Form Submissions In WordPress

I knew that despite this issue magically disappearing a couple of times now, it would be back and that it was somehow related to caching. I monitored my site for 1-2 months, periodically checking the lead magnet page and trying to submit the form and replicate the issue, to no avail. Every time I checked on it, it was working fine, until once again I looked at my analytics and saw 7 hits on the same day to the page without any sort of conversion. I popped open the browser and tried to submit the form and the pesky 403 error was back. This time I did some more advanced troubleshooting in the Chrome developer tools and got a firm understanding of the call stack for which this error was happening down to line numbers and scripts involved. I narrowed it down to Beaver Builder as the most likely vendor involved and went back and forth with them where we were able to identify the issue. Shoutout to Pross and the Beaver Builder team for their patience and dynamite support team! If you’re looking for a page builder for your WordPress site, which I highly recommend for startups and small businesses, you can sign up for them using our affiliate link. Anyways, the issue we discovered was due to WordPress caching the nonce that gets submitted along with the form for longer than the nonce’s lifespan.

What Is A Nonce In WordPress?

A nonce is short for “number used once” and is simply a unique identifier for a request that verifies its authenticity. A nonce passed along with requests, such as AJAX form submits, helps defend against a number of common cyber attacks and keeps your information secure. See this codex entry on nonces for more information.

Understanding The Relationship Between Nonce Expiry And Cache Expiry

A WordPress nonce, once generated, is valid for a minimum of 12 and a maximum of 24 hours depending on a couple of factors. Most forms will submit their nonce via a hidden field value which is cached along with all the other HTML of a page by many WordPress hosting providers. If you’re like me and a lover of all things SEO and page speed, you want to maximize the number of speedy visits you can generate on your website. You or your host may have your cache expiry set to a duration longer than 12 hours. If this is the case and you’re using forms on your website that rely on WordPress nonces you are likely encountering issues where people cannot submit forms your forms to either contact you or to subscribe to your email list. In my case, I had a 7-day cache expiry set so I was only encountering this issue on days 2,3,4,5,6 after publishing a new version of the page. Since I was only checking for the issue a couple of times per month to look for it, I was likely past the 7-day cache expiration and getting a hard reload and successful form submission with an active nonce. Day 1 and Day 7+ would make everything appear to be working correctly. Once this issue was discovered I shortened my cache expiry to 8 hours, which is below the 12-hour guaranteed nonce validity window in WordPress, and resolved this issue for good.

Note, that nonce timelines can be customized, so if you’re working on a sophisticated WordPress site, these times can change, but the default settings come with a 12-hour minimum and 24-hour maximum lifespan.

Further Reading: WordPress Caching And Nonce Lifespans

Wrapping Up

This was a complex issue, that was only presenting under very specific circumstances. It was one that could easily elude even experienced developers due to its intermittent nature. I hope you enjoyed this post and hope that it helps save someone some time in the future. Thanks for reading.