Search engines and analytics count URLs and status codes, not screens — design the signal you send to machines separately

Your site looks fine to people. Change a filter and the map follows. Open a deleted post and a friendly "Not found" appears. The home page opens in the right language. Yet search traffic has been flat for months and your analytics shows page views that make no sense. You stare at the screen and nothing is broken.

What search engines and analytics tools actually read

Search engines and analytics tools do not look at your page; they count URLs, HTTP status codes, redirect types, and browser history changes literally. A screen that is one page to a person can be tens of thousands of distinct pages to a crawler, and a screen that says "not found" to a person can be a perfectly normal page to a machine. Making the screen right and sending machines the right signal are two separate jobs, and they need two separate checks.

The gap is quiet. Nothing throws, nothing looks wrong, and the damage — missing index entries, wasted crawls, inflated metrics — shows up as numbers weeks or months later.

What leaks when UI state goes into the query string

If you link map coordinates, zoom level, or filters as ?lat=…&zoom=…, people see one map but the crawler sees one unique URL per combination. It spends your crawl budget fetching them one by one, and the content you actually just published waits.

• Put UI state the server does not need into the hash (#lat=…). The hash is never sent to the server, so the URL stays single
• If state must live in the query, give the page a canonical URL so there is one declared representative
• Add "does it have a canonical?" to the checklist for every new page type

Why language redirects should be 308, not 307

If you send the root / to your default language /en with a temporary redirect (302 or 307), the crawler reads it as "the real address is still /". It may pick / as the canonical and never index /en, where the content lives. Google's documentation treats permanent redirects (301, 308) as a strong signal that the target is canonical and temporary ones as a weak signal.

• If a path without a language always goes to a language path, make it permanent (308)
• List only languages that really exist in hreflang (the tags that map language versions), and add x-default. A hreflang entry that 404s weakens the whole cluster
• Do not stamp sitemap lastmod with the build time. It turns into "every page changed today" and the signal becomes noise

Why a "Not found" screen can return 200

With streaming rendering — send the shell first, fill content in later — the response headers leave with the first byte. If the data lookup finds nothing after that, you can still draw a not-found screen, but the status code is already locked at 200. Search engines treat it as a normal page or a soft 404, and old URLs of deleted posts and tags linger in the index. Calling notFound() inside a loading.tsx boundary in the Next.js App Router is a common case (Next.js docs on streaming and status codes).

• For URLs that became empty because content was deleted, a permanent redirect (308) to the parent listing sends the clearest signal
• If you need a real 404, decide "not found" outside the streaming boundary, before the first byte
• Don't rely on noindex alone. Check the status code yourself with curl -I

Why changing only the URL inflates page views

In a calculator that mirrors its inputs into the URL as you type, every history.replaceState call is counted as a page view by GA4's enhanced measurement option "page changes based on browser history events". The person edited a number on one screen; your metrics got one page view per keystroke.

• Turn that option off in the analytics console, or
• In code, capture history.replaceState with .bind(history) at module load, before the analytics script wraps history, and use that original for silent URL updates
• Before calling it done, capture the actual network hits and confirm "zero page_view while typing"

A checklist for every new screen

Before shipping a new screen or a routing change, look at it once more through the machine's eyes.

1. Does a state change on this screen create a new URL? If so, are those URLs consolidated with a canonical?
2. Is each redirect permanent or temporary? If it always goes there, is it 308?
3. Does the "not found" screen really return 404 (or 308)? Did you check with curl -I?
4. Does code that changes the URL get counted as a page view? Did you capture the real hits?
5. If you judge a fix by search console counts, did you first check when those counts were crawled (last crawl time)?

If an agent does this work, you can hand it this instruction:

When you change routing, redirects, or URL updates, verify the signal, not the screen:
- For every changed path, record the status code and Location from `curl -I` (does 404/308/200 match intent?)
- If UI state produces query strings, confirm a canonical URL is present
- If you call history.pushState/replaceState, capture analytics hits and report the page_view count
Do not report "done" just because the page looks right.

What happened to us

• Wasted crawls: on a local information service, map state was linked through query strings, and the search console piled up about 15,000 URLs as "Crawled – currently not indexed". Only after downloading the URL list did the map coordinate combinations show up as the cause.
• Temporary redirect: a bilingual site sent / to its default language path with a 307, and search clicks over six months totaled one. We switched to permanent redirects and cleaned up hreflang.
• A 404 that returned 200: URLs of deleted items stayed in search results, so a brand-name search landed on a "not found" screen. The response status was 200 — "not found" was being decided inside a streaming boundary.
• Inflated page views: in a calculator that synced inputs to the URL, each keystroke was one page view. After switching to the captured original replaceState, a network capture showed zero page_view hits across three typed characters.
• One more: after a fix, search console counts did not move and we almost logged "no effect". Google simply had not come back yet; we should have checked the URL inspection's last crawl time first.

In every case the screen was right from the start. What was wrong was the signal sent to machines, and no check that looked at the screen ever caught it.