404 tracking

Clickport records when a visitor lands on a page that does not exist. Every 404 hit is collected under its own sub-tab in the Pages panel, so broken links stop being invisible.

For most sites there is nothing to configure. Detection works out of the box with any error page whose title says so.

How detection works

When a page loads, the tracker checks the document title. If it contains 404 or not found (case-insensitive), the pageview is flagged as a 404. That covers the default error pages of WordPress, Shopify, and most themes and frameworks.

If your error page uses a custom title ("Oops, nothing here") or a non-English one ("Seite nicht gefunden"), set an explicit flag in your 404 template instead, before the tracker snippet:

<script>
  window.cpConfig = window.cpConfig || {};
  window.cpConfig.is_404 = true;
</script>

The explicit flag is the more robust option even when auto-detection would work, because it does not depend on the title staying the same. See Script Configuration for the full cpConfig reference.

Where 404s appear

Open the Pages panel and switch to the 404 sub-tab. Each row is one broken URL with the number of hits it received in the selected date range, sorted by hits.

The list usually splits into three kinds of rows, and each kind has a different fix:

• Deleted or moved content (/blog/old-post, /pricing-2024). Someone still links to it. Add a redirect to the closest live page.
• Broken internal links (typos in your own hrefs). Fix the link at the source. The Sessions drill-down below tells you which page carries it.
• Probe noise (/wp-login.php, /.env, /admin). Scanners guessing common paths. Nothing to fix; most of this traffic is already filtered by bot detection, and what remains is safe to ignore.

Finding where the broken link lives

Click a 404 row to filter the whole dashboard to visitors who hit that URL. Then open the Sessions panel: each session timeline shows the page the visitor was on right before the 404. If the previous page is one of your own, that page contains the broken link. If the session starts on the 404 itself, the bad link is external or from a search engine, and the session's referrer tells you where it came from.

Exports

The 404 list is part of the CSV export ZIP as error_pages.csv with two columns: path and hits.

What is not caught

• Client-side route changes. On single-page apps, detection runs on the initial page load. A "not found" view rendered by the client router on a later navigation is not flagged. If your SPA serves a real 404 route, set cpConfig.is_404 on it. See SPA Tracking.
• Soft 404s with clean titles. The tracker cannot see HTTP status codes. A missing-content page titled like a normal page needs the explicit flag.
• Broken images and scripts. Resource-level 404s (a missing image on an otherwise fine page) are not page 404s and are not counted here.
• Direct file hits. A 404 is only recorded if your error page loads and runs the tracker. A missing PDF that returns a bare server error page without the snippet leaves no trace.

Good to know

• Hits are raw pageview counts, not unique visitors. One frustrated visitor reloading a dead URL five times counts five hits.
• 404s cannot be used as a goal. If you want to alert on them, filter the dashboard by the 404 path and watch the trend instead.
• For the deeper story on why 404 tracking matters and how to do it elsewhere, see our article on tracking 404 pages.

Related

• Panels - The Pages panel and its sub-tabs
• Site Search Terms - The neighbor sub-tab: what visitors look for
• Script Errors - JavaScript errors visitors run into