Perplexity documents PerplexityBot for search and Perplexity-User for user-requested fetches, with official IP JSON endpoints. WordPress sites that use a WAF or CDN need to verify both robots.txt policy and network access before judging AI search visibility.
Use this when Perplexity does not cite a WordPress page, WAF logs show 403 or managed challenge responses, or a site wants to allow search crawlers without opening the door to spoofed bots.
Quick answer
PerplexityBot WAF Rules for WordPress AI Search should be handled with a narrow evidence-first workflow: check robots.txt, fetch ip ranges, tune waf, then verify the result before making broader changes.
What to check first
- Confirm robots.txt allows PerplexityBot for public pages that should appear in AI search.
- Use official Perplexity IP JSON endpoints when building WAF allow rules.
- Combine IP checks with user-agent checks instead of trusting the user-agent string by itself.
- Review CDN, WAF, host, and security plugin logs for 403, 429, challenge, or captcha responses.
- Retest public pages, images, CSS, JavaScript, and sitemap URLs after WAF changes.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|---|---|
| Check robots.txt | Confirm robots.txt allows PerplexityBot for public pages that should appear in AI search. | PerplexityBot receives 200 responses for public pages and sitemap files. |
| Fetch IP ranges | Use official Perplexity IP JSON endpoints when building WAF allow rules. | WAF allow rules use official IP ranges and user-agent conditions together. |
| Tune WAF | Combine IP checks with user-agent checks instead of trusting the user-agent string by itself. | Private, staging, checkout, and account pages remain protected. |
| Review logs | Review CDN, WAF, host, and security plugin logs for 403, 429, challenge, or captcha responses. | Logs show normal crawler volume after the change. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -A 'PerplexityBot' -sSI https://example.com/robots.txt
curl -A 'PerplexityBot' -sSI https://example.com/sitemap.xml
curl -sS https://www.perplexity.com/perplexitybot.json | head
# Match official IP ranges in WAF rules before allowing crawler traffic.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Check robots.txt
- Fetch IP ranges
- Tune WAF
- Review logs
- Retest crawl paths
Production verification checklist
- PerplexityBot receives 200 responses for public pages and sitemap files.
- WAF allow rules use official IP ranges and user-agent conditions together.
- Private, staging, checkout, and account pages remain protected.
- Logs show normal crawler volume after the change.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, review WordPress AI crawler access.