CrawlCheck

Findings · 2026-09-10 · By · 0 views

The Denver Post publishes coordinates that put its newsroom 10,668 km away

One character. The address in the same block says 5990 Washington St., Denver. The coordinate two lines below it says northern China, and every check we run passed it as valid.

On 10 September 2026 we read the structured data on the front page of denverpost.com. Inside a LocalBusiness node describing the newspaper sits a GeoCoordinates block: latitude 39.7392, longitude 104.9903. The address in the same node reads 5990 Washington St., Denver, CO 80216. Those two facts are 10,668 kilometres apart.

Denver is at longitude minus 104.9903. The published value has no minus sign. Plotted as written it lands in northern China.

What the page declares

The node is not obscure and it is not stale markup left in a comment. It carries the newsroom street address, the postal code, the switchboard number, the newsroom email address and an opening-hours block. Everything in it is correct except the one field a human never reads. Coordinates are the only property in that block written purely for machines, and it is the only one that is wrong.

That is worth sitting with, because it is the general shape of this class of defect. Nobody proofreads a number that never renders. There is no page on the site where the mistake is visible. A reader cannot see it, an editor cannot see it, and the analytics will never report it. The only party that reads it is a parser, and a parser has no opinion about whether a Denver paper belongs in Asia.

Where 39.7392, -104.9903 comes from

The pair is not a measurement of the building. 39.7392, -104.9903 is the Denver city centroid, the coordinate every template, plugin and tutorial reaches for when it needs "Denver". We see it elsewhere in our own corpus: a Colorado tree-care site declares exactly the same pair. The building at 5990 Washington St. is about a mile and a half north-east of it.

So the likely history is ordinary. Someone pasted a city centroid into a template field, and somewhere between the paste and the render the minus was lost - a spreadsheet column typed as text, a CMS field that strips leading characters, a copy that took the digits and not the sign. The value stayed plausible-looking the whole way. It has four decimal places. It sits at a real latitude. It simply points at the wrong hemisphere.

Our own check passed it, and that is the part worth publishing

This scanner runs a coordinate-integrity test on every local node it finds. On this page it returned: one pair found, valid true, null island false, duplicates zero, low precision zero. A clean row. The test asks whether the latitude is inside plus or minus 90 and the longitude inside plus or minus 180, whether the pair is sitting at 0,0, whether two locations share one coordinate, and whether there are enough decimal places to be worth anything. A sign flip passes all four. 104.9903 is a perfectly legal longitude.

Which is the honest limit of a range check, and we would rather say it here than have someone find it: a rule that only knows the shape of a number cannot tell you the number is about the wrong place. Catching this one needs a second fact to disagree with - and the second fact was sitting in the same node the whole time, in the addressCountry and addressRegion fields.

What each rule catches, and what it does not

Rulewhat it testsCatchesWould it catch this
Range|lat| ≤ 90, |lon| ≤ 180Transposed pairs, corrupted values, degrees written as minutesNo - 104.9903 is a legal longitude
Null islandboth values near zeroEmpty template fields rendering as 0,0No
Precisionfewer than three decimalsCity-level coordinates sold as a storefront pinNo - four decimals
Duplicatestwo locations, one pairA centroid copied onto every branchNo - one location
Address agreementdeclared country vs hemisphereSign flips, wrong-hemisphere pastesYes

Four of those five rules are live in this scanner today. The fifth is not, and this page is why we know we want it.

What it costs, stated carefully

We are not going to tell you this is why anything ranks where it ranks. We cannot see inside anyone’s ranking system, and a newspaper of this size has hundreds of stronger location signals - a Google Business Profile, decades of citations, an address printed on the masthead. Any sensible consumer weighing a declared coordinate against all of that will discard the coordinate.

What is checkable is narrower and still worth knowing. Anything that reads this node and trusts the coordinate over the address gets northern China. That includes the naive case, which is more common than it sounds: a script that wants a lat/long and takes the one the page hands it. It also includes us. Our registry plots measured sites at the coordinates they declare, so the light for denverpost.com sits over China on the globe, exactly where the page says to put it. We are not correcting it. Plotting what a site declares is the whole point of the layer, and a light in the wrong place is the finding.

How we found it

Not by looking for it. We were building a map of every measured domain that declares its own coordinates, reading the values straight out of stored scan records. Eight of 233 domains in the corpus declare a coordinate at all - most sites are not local businesses and correctly declare none. Seven of the eight landed in Colorado. One landed in Asia, and it was the newspaper.

That is a small enough sample to say plainly: one in eight of the coordinate-declaring sites we happen to have measured is pointing at the wrong hemisphere. We are not going to extrapolate a rate from eight records. The interesting part is not the frequency. It is that a defect this total can sit on a major publisher’s front page and generate no symptom anyone would notice.

How to check yours in about a minute

Open your own front page, view source, and search for GeoCoordinates. If there is a block, read the longitude. Anywhere in the Americas it should start with a minus sign. Then read the address in the same node and ask whether the two agree about which side of the planet you are on. If your site declares no coordinates at all, that is not a defect - a coordinate you cannot keep correct is worse than none, and an accurate postal address does more work.

If it does declare them, one more question: where did the pair come from? If it is your city’s centroid rather than your building, every business in your city is claiming the same point, and none of them is distinguishable by it. Our registry record for this domain shows what we hold, the dataset page shows how every finding rate here is computed, and the last time a defect in our own reading reached a report is written up too.

What this post does not claim

It does not claim the Denver Post is hard to find, that its search performance is affected, or that anyone at the paper is careless. It claims one thing, which anyone can verify in a browser in under a minute: the coordinate published on that page is 10,668 km from the address published beside it, and the check we run today says the coordinate is fine.

Every figure above came out of this scanner.

Point it at your own domain and see the same measurements, free.

Scan a domain — free

Related findings

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works