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.
That is the only location this site will show. When a network publishes a geofeed we read it and draw the declared city; when it does not, we show no location at all rather than repeat an estimate as though it were a fact. It means our maps appear less often than a competitor's, and it means the ones that appear can be checked against the operator's own file.
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.