An embedded form runs on its source WordPress site. A challenge or anti-spam script placed only on the outer static page does not automatically protect the form inside the iframe.
Start with your form plugin’s supported protection
Choose an anti-spam method supported by the form builder and the protection plugin you use. Honeypots, challenge services and server-side checks have different requirements. Avoid stacking several methods before testing each one independently.
Configure the source hostname
If a challenge service uses allowed hostnames, configure the hostname serving the WordPress form. Review its official documentation for embedded or cross-origin requirements. The parent page and iframe source are different origins even when they share a brand.
Check scripts and caching
Test from a logged-out browser. Make sure required scripts load, the challenge is visible when expected, and caching has not served stale tokens or an old form. Check with the actual cache and optimisation plugins enabled.
Test acceptance and rejection
Confirm that a legitimate submission is stored and reaches the intended notification or integration. Then use the protection tool’s documented testing method to verify rejection. A blocked submission should not show a successful confirmation or trigger the parent redirect.
Check usability
Try keyboard navigation, a phone-sized layout and any privacy or script-consent configuration. If a visitor cannot complete a challenge, provide a useful way to contact you. Keep an eye on false positives after launch.
Keep a short test record
Record the source form URL, parent page, protection settings, cache configuration and date tested. Repeat the checks after changing form, anti-spam or optimisation plugins.