Response Pages are what a refused visitor actually sees. For most of them the block is a mistake — a customer on a hotel network, a rule slightly too strict — so this page decides whether they see a wall or a way to reach you.

Two levels of effort, and the first is usually enough:
Branding applies to the pages EdgeGuard already has — you change how they look without writing any HTML:
Press Save Branding and every built-in page follows.

Templates replace a page entirely with your own HTML, for when the branding is not the point — a different language, a support form, a corporate shell.
Click New Template.

The engine looks for a template in this order and stops at the first it finds:
Tenant → Group → Global → the built-in default
So a site with its own block page keeps it; a site without one falls back to its group's, then to the global one, then to EdgeGuard's own. There is always a page: a site that has configured nothing still gets a sensible one.
These placeholders are filled in when the page is served:
| Placeholder | What it becomes |
|---|---|
{{brand_name}} |
the brand name from Branding |
{{brand_logo}} |
the uploaded logo |
{{brand_color}} |
the accent colour |
{{reason}} |
why the request was refused |
{{timestamp}} |
when, in UTC |
{{ray_id}} |
the EdgeGuard ID of that request |
{{client_ip}} |
the visitor's address |
{{privacy_url}} |
the privacy policy link |
Always include
{{ray_id}}. It is the one thing that turns "your website blocked me" into a support conversation that can be resolved: pasted into the console's global search, it opens the exact request, the rule that refused it and what it matched on. A block page without it costs an hour of somebody's day.
A minimal template that keeps what matters:
<!DOCTYPE html>
<html lang="en">
<head><meta charset="utf-8"><title>Request blocked</title></head>
<body>
<img src="{{brand_logo}}" alt="{{brand_name}}">
<h1>We could not complete that request</h1>
<p>{{reason}}</p>
<p>If you believe this is a mistake, contact support and quote this reference:</p>
<p><strong>{{ray_id}}</strong> — {{timestamp}}</p>
<p><a href="{{privacy_url}}">Privacy policy</a></p>
</body>
</html>
Trigger each page you have customised and look at it as a visitor:
# A block page
curl -s "https://site.example.com/?id=%27%20OR%201%3D1--" | head -40
# A rate limit page: exceed a rule you own
for i in $(seq 1 50); do curl -s -o /dev/null "https://site.example.com/api/search?q=x"; done
curl -s "https://site.example.com/api/search?q=x" | head -40
Check that the reference shown matches an event: paste the EdgeGuard ID from the page into the console's global search. If it opens the request you just made, the loop your support desk depends on is working.