Clickport
Start free trial
Intuitive Dashboard Engagement Tracking Session Tracking Goal Conversions Filtering & Segments Privacy First Real-Time Analytics Ask your analytics Bot Protection
For agencies For SaaS For e-commerce For affiliates For bloggers For publishers Google Search Console Bing Webmaster Tools WordPress Shopify Tracker install SPA tracking Custom Events API reference vs Google Analytics vs Matomo vs Cloudflare All comparisons
How It Works Blog Updates Documentation UTM Builder GDPR Checker GA4 Data Loss Estimator GA Legal Status GA Problems WordPress Analytics Bot Traffic AI Traffic Ecommerce Analytics About Contact Status Security

Block pages

The page block list rejects events for specific URL paths. Useful for keeping internal admin routes, staging pages, login screens, and other operational URLs out of your real analytics. Add rules from /<domain>/settings/tracking-rules.

When to use it

  • Admin and back-office pages. If you have a route like /admin or /wp-admin that only your team uses, blocking it cuts internal traffic out of every report without anyone having to flip a personal toggle.
  • Staging and preview routes. Marketing and devs reviewing draft pages can stay invisible to your analytics. /preview/*, /staging/*, or whatever convention you use.
  • Auth flows. Login, password reset, magic link landing pages. These pages get inflated session counts because users hit them repeatedly. Hiding them gives you cleaner engagement metrics on the pages that actually matter.
  • Error pages. If you want 404s out of your dashboard entirely, block /404 or whatever your error page slug is. (Note: 404 detection is handled separately by the tracker.)

Adding a page rule

Open Settings → Tracking rules, find the Pages card, and click Add. The path must start with /. Examples:

  • /admin: exact match. Only /admin is blocked, not /administration or /admin/users.
  • /admin/*: prefix match. Everything under /admin is blocked, including /admin itself.
  • /wp-admin/*: WordPress admin area.
  • /preview/*/draft: a wildcard in the middle. Matches /preview/v2/draft, /preview/article-42/draft, etc.
  • /login, /reset-password, /verify-email: auth flow pages.

How wildcards work

The * wildcard matches any sequence of characters, including slashes and the empty string. Some examples to build intuition:

  • /blog/* matches /blog/hello, /blog/2026/05/title, and /blog/. Does not match /blog (no trailing slash, no characters after).
  • /blog* matches /blog, /blog/, /blog/anything, and also /blogger.
  • */draft matches anything ending in /draft: /preview/draft, /articles/2026/draft.

Wildcards are compiled to regex at the moment you save the rule, so matching at ingestion time is O(1) per event. The compiled pattern is escaped against regex metacharacters before the wildcard is replaced, so a path like /(test) is matched literally as /(test), not as a regex group.

What the path is matched against

The tracker sends the full URL of the page. The server extracts the path and runs a normalization step:

  1. Tracking parameters stripped. ?utm_source=..., ?fbclid=..., and other tracking params are removed before matching.
  2. Per-site rewrites applied. If you've set up path normalization (e.g., merging /post-123-slug into /post-:id), the rewritten form is what the rule sees.
  3. Trailing slashes preserved. /admin and /admin/ are different paths to the rule.

If your rule isn't matching, the normalized path is probably different from what you expected. Open the Sources or Pages panel for a recent visit to see exactly what the tracker recorded.

Limits

  • 100 rules per site. Each rule is one path (or one wildcard pattern). For an extensive list of admin routes, consolidate them under a wildcard: instead of 12 rules for individual admin pages, use /admin/*.
  • Max 200 characters per path. URLs longer than that probably aren't human-typed routes worth blocking.
  • No spaces in the path. Use percent-encoding or strip them from the rule.

Troubleshooting

My rule has a wildcard but it's not matching

Check what path the tracker actually sees. Open your dashboard's Pages panel, find a recent visit to the path you tried to block, and compare. Common surprises:

  • You used /blog/* but the page is exactly /blog (no trailing slash, nothing after). Use /blog* or add a second rule for the bare path.
  • Your path normalization rewrites /post-123 to /post-:id. The rule must match the rewritten form.
  • Query parameters that aren't tracking params (like ?search=foo) are kept. /search won't match /search?q=foo directly; you'd need /search*.

I blocked /admin but my admins still show up

Page block rules drop the matching pageview, but the admin user's earlier or later pageviews on other paths are still recorded. To hide a user across all pages, use the IP block (for fixed networks) or the personal device toggle (for individual browsers). Page blocking only filters specific paths.

How do I block all paths except a few?

There's no "allow-list" mode for pages in v1. If you want to track only / and /about, you'd have to enumerate all other paths, which doesn't scale. Consider whether a different filter (hostname allow-list, country block) achieves the same goal more cleanly.

Previous Block countries