Every detector has a last line, and that line decides who gets served when nothing is known

Write the fallback down, in the code and on the page. The last line of any detector is a choice about who gets served when nothing can be determined, and it is usually the only line nobody can explain six months later. Ours defaults to India when it can tell nothing about a visitor, and that is deliberate rather than lazy: it protects a buyer whose handset ships with a foreign locale from being quoted a price ladder 2.2 times his own. When we audited the page that uses it, the default turned out to be correct and the page around it was wrong. Knowing which of those two it was took an afternoon, and it would have taken five minutes if somebody had written a sentence.

The reason this is worth a page rather than a code comment is that a crawler reaches the fallback on every request it ever makes. A browser supplies plenty of evidence about itself and almost never falls through. An automated fetcher supplies none, so the branch you wrote for the rare unknown case becomes the only branch that machine ever executes.

Why defaults go undocumented

Three reasons, and they are the same three everywhere.

• It is written last, in a hurry. The interesting cases are the detected ones. The fallback is the line you add so the function returns something.
• It is correct for the case the author pictured. Our fallback is genuinely the right answer for the visitor it was written for, which is why nobody questioned it and why nobody recorded the reasoning either.
• Nothing exercises it during development. Everyone building the feature has a browser, a locale and a time zone. The branch that handles their absence is the one that never gets tested by a human being.

So the branch with the least documentation and the least testing is the branch that serves every automated reader of your site. That is the inversion worth fixing.

What the signals look like from both sides

Our own region logic reads five signals before it gives up. Three of them are a network country header added by the delivery layer, a time zone recorded in a cookie, and the language preference a browser announces. A crawler sends none of them.

Signal	A browser	A plain fetcher
Network country header	Usually present	Absent
Time zone cookie	Present after a first visit	Absent, no cookie jar
Language preference	Present	Absent unless somebody sets it deliberately
Result	A detected answer	The last line, every time

Read the bottom row as a design brief rather than a bug report. Whatever your last line returns is your canonical answer for every machine that reads your site, so it should be the answer you would be happy to see quoted back to you by somebody you have never met.

What to actually write down

Six fields, kept next to the code and summarised in whatever internal document your team actually reads.

• The signals read, in order. Somebody will need to know which one wins when two disagree.
• What the last line returns, stated as a value and not as a variable name.
• Who it protects. Ours protects a specific buyer from a specific harm, and that sentence is the whole justification.
• What it costs the other cases. Every default is right for somebody and wrong for everybody else, and naming the loser is what makes the decision reviewable.
• The date and the owner. A default without a date cannot be reviewed, because nobody knows whether the reasoning predates the product it now serves.
• How to test it. For us that is a single fetch with no cookies and no language header, which is two flags on a command line client.

That last field is what turns documentation into something that stays true. A fallback with a one line reproduction command attached gets checked. A fallback described in prose gets believed.

A documented default is still only half of it

Here is the part our own audit taught us, and it is the more important half. Writing the default down would have saved us the time spent working out whether it was the bug. It would not have fixed anything, because the actual defect was that the alternatives were not in the document at all.

The detector chose correctly from what it had. The page then printed only the chosen answer, and the other regions existed only after a script ran, so an automated reader had one answer available to it and no sign that others existed. The repair was to print every region's figures on every request regardless of what the detector concluded, which makes the fallback almost irrelevant to the outcome. The equivalent decision for a site selling into several currencies at once is worked through in our page on one site, two currencies and the pricing page.

So the rule has two halves. Document the default, because somebody will have to judge it under pressure. Then make it matter less, by putting every value a reader might need into the first response, so the branch that was taken stops deciding what anybody can learn.

Questions about default behaviour when detection fails

What should a region detector return when it knows nothing?

Whichever answer causes the least harm to the visitor most likely to be misread, and then state that reasoning somewhere. There is no universally correct value, which is exactly why the choice needs a sentence rather than a convention.

Is a geographic default a cloaking problem?

Serving different visitors a view appropriate to them is ordinary. The line that matters is whether an automated reader gets a page a person would recognise, which is why putting every value in the document is the safe shape rather than branching harder.

How do I test my own fallback?

Fetch your page with a plain client, no cookies and no language header, and read what comes back. That one request takes the same branch every crawler takes, and if the result surprises you then the fallback has never been reviewed.

Should the fallback be a neutral option instead?

A neutral answer sounds safer and often serves nobody well. Ours is deliberately not neutral because a specific buyer would be harmed by the neutral choice, and that is a reasonable decision to make as long as it is recorded and reviewed.

Where does this belong, a code comment or a document?

Both, and the document is the one that survives a refactor. A comment explains the line to whoever is reading that file; a written policy explains the decision to whoever has to defend it to a customer.

The line nobody can explain is the line everybody gets

A fallback is the most quietly consequential code in a commercial site, because it is the branch serving every reader who cannot describe themselves, and that now includes the machines answering questions about your prices. Ours was right and undocumented, which cost us an afternoon of doubt; the page it sat behind was wrong, which cost us an American buyer reading rupees. We publish both halves with their dates, and the exports, windows and dated blind scan behind every other figure we quote are on our proof page. Finding this class of defect on other companies' sites and getting it repaired is what we sell. For a format to record decisions like this so they can be reviewed rather than rediscovered, our policy template you can copy section by section is a workable starting point.