How-to8 min readUpdated May 1, 2026

How to Track 404 Error Pages on Your Website

Q: Why not just use Google Search Console for 404 monitoring?

Search Console only shows 404s Google encounters during crawls — it lags by days or weeks and misses 404s from email links, social media, and direct traffic. Analytics-based 404 tracking is real-time and covers every browser visit, not just Googlebot.

Q: Do 404 events need cookie consent in the EU?

With Sleek, no — the event contains the broken URL and a coarse referrer classification, none of which are personal data. With Google Analytics, you would need consent because GA4 sets cookies on every pageview including the 404.

Q: How do I track 404s in a Next.js app?

Put the `window.sleek("track", "pageview_404", ...)` call inside your `not-found.tsx` (App Router) or `pages/404.tsx` (Pages Router) inside a `useEffect`. Make sure the analytics script is loaded in your root layout so the global function exists.

Q: Should I redirect every 404 I see?

No. Redirects are debt — every redirect is a rule you have to maintain. Redirect when the URL has meaningful traffic from a source you cannot fix (search results, external links). For one-off typos with two visits in a year, leave them alone.

Q: Can I track 404s on static sites hosted on Vercel/Netlify/Cloudflare Pages?

Yes. As long as the host serves a 404 HTML page (most do by default) and that page includes your analytics snippet, the tracking works the same way. Vercel and Netlify both let you customize the 404 page.

Q: Will a 404 tracker hurt my SEO?

No. The tracker fires on the 404 page, which Google already understands as a soft signal. The tracker does not change the HTTP status code (still 404) and does not add crawl depth. SEO best practice for 404s is a fast, clear page with navigation back to the rest of the site — adding analytics does not change that.

Q: How do I see "what URL would have worked" alongside the broken URL?

Most teams add a search box on their 404 page and track searches as a separate event. Pair the `pageview_404` data with the search-from-404 data and you can see where readers were trying to go. Sleek lets you join these in the AI chat: "for visitors who hit a 404 last week, what did they search for next?"

A pragmatic guide to monitoring 404 errors with privacy-friendly analytics. HTML snippet, event tracking code, and a workflow for fixing broken links.

track 404 errors404 page analyticsbroken link monitoringpage not found tracking404 error reportfix 404s seo

TL;DR

1.404 errors are the cheapest SEO wins on the internet — every fixed broken link is recovered traffic.
2.Fire a custom `pageview_404` event from your 404 page so you can see, in real time, what people are trying to reach.
3.Capture both the broken URL and the referrer so you know whether the link came from your site or someone else's.
4.Set up a weekly review: top 10 broken URLs, fix or redirect each, repeat.
5.Avoid logging full query strings — they often contain tokens that should not live in analytics.

Why 404 tracking is worth ten minutes of your time

Almost every website has 404 errors that nobody is looking at. Old blog posts moved without redirects, typo'd links from external sites, marketing campaigns that pointed to a URL that never existed. Each one is a person who wanted to reach your site and instead got a dead end.

The fix is almost always cheap — a 301 redirect, a typo correction, a search-friendly 404 page. The hard part is knowing the 404 happened in the first place. Server logs work but they are noisy and hard to filter; analytics gives you a clean, actionable list.

In this guide we set up a `pageview_404` event that fires from your 404 page, captures the broken URL and the referrer, and shows up in your Sleek dashboard alongside everything else.

Step 1: install Sleek

Make sure your 404 page actually loads the analytics script. Lots of teams accidentally serve a static HTML 404 that does not include their tracking tag, and then wonder why they cannot see their 404s. Check the source of your 404 page in a browser — if you do not see the Sleek snippet there, fix that first.

404.html

<script async src="https://getsleek.io/v1.js" data-site="YOUR_SITE_KEY"></script>

Step 2: fire a `pageview_404` event from the 404 page

A normal pageview already fires automatically when the 404 page loads. We want a second, custom event that flags this pageview as a 404 so it does not get lost in the regular pageview stream. The custom event also lets us send the broken URL and referrer as properties.

404.html

// Place this near the bottom of your 404 page, after the Sleek snippet.
window.sleek('track', 'pageview_404', {
  // The URL the user actually tried to reach.
  attempted_url: window.location.pathname,
  // Where they clicked from (could be your site, Google, or another domain).
  referrer: document.referrer || 'direct',
  // Browser language can hint at translated-page bugs.
  language: navigator.language,
})

tip:If your site uses a single-page-app router that handles unknown paths client-side, fire the event from your "not found" route component instead of from a server-rendered 404 page.

Step 3: separate internal vs external broken links

Not all 404s deserve the same response. A broken link from your own homepage is a code change you should ship today. A broken link from a typo on Reddit five years ago is at most a candidate for a redirect, and only if the URL gets meaningful traffic.

The referrer property lets you split these in your dashboard. Add a small helper that classifies the referrer before sending:

404.html

function classifyReferrer(ref) {
  if (!ref) return 'direct'
  try {
    const host = new URL(ref).hostname
    if (host === window.location.hostname) return 'internal'
    if (/google|bing|duckduckgo/.test(host)) return 'search'
    return 'external'
  } catch (e) {
    return 'unknown'
  }
}

window.sleek('track', 'pageview_404', {
  attempted_url: window.location.pathname,
  referrer_type: classifyReferrer(document.referrer),
  referrer_host: document.referrer ? new URL(document.referrer).hostname : null,
})

Step 4: build the weekly broken-link review

Tracking 404s is only useful if you act on them. Set up a weekly fifteen-minute ritual:

Open your Sleek dashboard, go to Events → `pageview_404`, set the date range to the last 7 days.
Group by `attempted_url` and sort by count.
For each of the top 10 URLs, decide: redirect to a real page, fix a typo in the source, or leave alone if it is genuine spam traffic.
Apply the redirects in your CDN, framework, or `vercel.json` / `next.config.js` — wherever your routing lives.
Mark the entries as resolved (a Notion doc or a one-line changelog is enough). Move on.

Step 5: alert on spikes

Most weeks your 404 count is flat. The interesting moments are spikes — a deploy that broke a popular URL pattern, a marketing campaign that pointed at the wrong landing page, a site migration that missed a section.

Sleek has a Goals → Alerts feature where you can set a threshold on any custom event. Set it to alert when `pageview_404` count exceeds your usual daily volume by 3x. The first alert in the wild will probably catch a real bug; subsequent alerts catch the rest.

warning:Do not include full query strings in `attempted_url`. Auth tokens, password reset codes, and email addresses sometimes end up in URLs that 404, and you do not want any of that in your analytics. Strip everything after `?` before sending.

How this differs from server logs

Server logs catch every 404 — including bots probing for `/wp-admin.php` and other vulnerability scans. That is useful for security monitoring but noisy for the SEO-and-broken-link use case. The analytics-based approach in this guide only catches 404s seen by real browsers, which is what you actually want when you are deciding what to redirect.

For full coverage, run both. Use server logs for security-style alerts (sudden spike in 404s suggests a scan) and use analytics for human-traffic 404s (sudden spike suggests a broken deploy or a popular external link gone wrong).

Common patterns to watch for

Trailing-slash mismatches: `/blog/foo` works, `/blog/foo/` 404s (or vice versa). Standardize and redirect.
Old date-based URLs: `/2024/01/post-name` after you switched to `/blog/post-name`. Add a regex redirect.
Case sensitivity: `/About` 404s when the canonical is `/about`. Lowercase your routes.
Translation gaps: `/de/blog/foo` 404s because the German translation does not exist. Either translate or fall back to the English version.
Trailing punctuation: links from email clients sometimes include trailing periods or parentheses. Strip them in middleware.

Frequently asked questions

Why not just use Google Search Console for 404 monitoring?

Search Console only shows 404s Google encounters during crawls — it lags by days or weeks and misses 404s from email links, social media, and direct traffic. Analytics-based 404 tracking is real-time and covers every browser visit, not just Googlebot.

Do 404 events need cookie consent in the EU?

With Sleek, no — the event contains the broken URL and a coarse referrer classification, none of which are personal data. With Google Analytics, you would need consent because GA4 sets cookies on every pageview including the 404.

How do I track 404s in a Next.js app?

Put the `window.sleek("track", "pageview_404", ...)` call inside your `not-found.tsx` (App Router) or `pages/404.tsx` (Pages Router) inside a `useEffect`. Make sure the analytics script is loaded in your root layout so the global function exists.

Should I redirect every 404 I see?

No. Redirects are debt — every redirect is a rule you have to maintain. Redirect when the URL has meaningful traffic from a source you cannot fix (search results, external links). For one-off typos with two visits in a year, leave them alone.

Can I track 404s on static sites hosted on Vercel/Netlify/Cloudflare Pages?

Yes. As long as the host serves a 404 HTML page (most do by default) and that page includes your analytics snippet, the tracking works the same way. Vercel and Netlify both let you customize the 404 page.

Will a 404 tracker hurt my SEO?

No. The tracker fires on the 404 page, which Google already understands as a soft signal. The tracker does not change the HTTP status code (still 404) and does not add crawl depth. SEO best practice for 404s is a fast, clear page with navigation back to the rest of the site — adding analytics does not change that.

How do I see "what URL would have worked" alongside the broken URL?

Most teams add a search box on their 404 page and track searches as a separate event. Pair the `pageview_404` data with the search-from-404 data and you can see where readers were trying to go. Sleek lets you join these in the AI chat: "for visitors who hit a 404 last week, what did they search for next?"

Track your own growth loop

Sleek Analytics gives you visitors, sources, pages, devices, and real-time behavior with one lightweight script. No cookies, no GDPR banners.

Get Started Read the docs →

How to Track 404 Error Pages on Your Website

TL;DR

Why 404 tracking is worth ten minutes of your time

Step 1: install Sleek

Step 2: fire a `pageview_404` event from the 404 page

Step 3: separate internal vs external broken links

Step 4: build the weekly broken-link review

Step 5: alert on spikes

How this differs from server logs

Common patterns to watch for

Frequently asked questions

Why not just use Google Search Console for 404 monitoring?

Do 404 events need cookie consent in the EU?

How do I track 404s in a Next.js app?

Should I redirect every 404 I see?

Can I track 404s on static sites hosted on Vercel/Netlify/Cloudflare Pages?

Will a 404 tracker hurt my SEO?

How do I see "what URL would have worked" alongside the broken URL?

Track your own growth loop

Related reading

How to Track Outbound Link Clicks (2026 Guide)

How to Track File Downloads with Privacy-Friendly Analytics

How to Track Scroll Depth Without Cookies

Sleek vs Google Analytics (2026): Which Is Better for Modern Teams?