Know which response is being replaced
Custom pages cover distinct Cloudflare responses such as challenges, WAF blocks, rate-limit blocks and origin errors. Customising one type does not change the others, the HTTP status or the rule that caused the response.
Host the page independently
The custom page must be available over HTTPS and should not depend on the same origin, scripts, fonts or API that may be failing. Use small self-contained HTML and accessible contrast. Do not include secrets or dynamic customer data.
Keep required placeholders
Each page type requires specific Cloudflare placeholders. Preserve them exactly so challenge widgets, incident identifiers and diagnostic content can be inserted. Removing a required token can make the page invalid or prevent a visitor from completing a challenge.
Write useful incident copy
Explain what the visitor can do next without promising a recovery time. Preserve a support or reference identifier where supplied. A branded page should still distinguish a security block from an unavailable origin so customers and support can diagnose the correct problem.
Test without harming production
Use a test hostname or a narrowly scoped temporary rule to trigger the exact response type. Confirm HTTPS loading, placeholders, keyboard use, mobile layout, status code and behaviour when external assets are unavailable. Remove the temporary trigger immediately afterwards.
Plan availability and rollback
Custom error pages require an eligible Cloudflare plan. If the current plan does not include them, the default Cloudflare pages remain active. To recover from a broken custom page, return that page type to the Cloudflare default and verify the original diagnostic response.
