Where the guesses come from
Commercial databases assemble location estimates from the registrant's postal address in registry records, from city names and airport codes that operators embed in reverse DNS, from network latency measurements, and from data volunteered by apps and devices that also knew their GPS position.
Each of those is a genuine signal and each has a failure mode. A registrant address is a head office, which for a national provider may be a thousand kilometres from the equipment. A reverse DNS token is a naming convention nobody is obliged to keep current. Latency triangulation degrades badly wherever the network path is not geographically direct.
Country is usually right; city often is not
Country-level accuracy is generally good, because it is anchored in the registry allocation, which is a matter of record rather than an estimate. Independent evaluations consistently put city-level accuracy far lower — and lower still for mobile networks, where an address may be assigned from a pool serving an entire region, and for connections behind carrier-grade NAT, where one address covers thousands of subscribers at once.
The failure is not random, either. Addresses that cannot be placed precisely tend to be placed at a country's geographic centre, which is how a handful of unlucky rural addresses have ended up receiving years of misdirected complaints.
The one source that actually knows
RFC 8805 defines a geofeed: a CSV file an operator publishes, listing its own prefixes and where they are deployed. The operator is the only party who genuinely knows this, and publishing it is a deliberate statement.
Where a network publishes one, we read it and show the declared city with a link to the file it came from — a claim anyone can check at its source. Where it does not, we fall back to the free DB-IP city database we compile ourselves, and we label the result for exactly what it is: an estimate, with the radius it is good to, shown beside the registry's country of allocation so that the fact and the inference are never confused for each other.
What to do when a site has you in the wrong place
The site is almost certainly reading a commercial database, and the fix is with the database vendor, not the site. The major providers each publish a correction form. Your provider can also help by publishing an accurate geofeed, which fixes the problem at the source for every consumer of the data at once.
If you are using a VPN, the wrong location is the tool working as intended: the address a site sees belongs to the VPN's exit server.