geo.placename: what geo meta tags do and who reads them

What geo.placename is

geo.placename is a <meta> tag naming the city or locality a page is about. It travels with three others: geo.region holds an ISO 3166-2 country and subdivision code, geo.position holds latitude;longitude, and ICBM holds the same coordinates comma separated. None of the four is a web standard. They were proposed in an IETF Internet-Draft that expired in 2008 and never became an RFC.

Google says it “ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes”, so adding them will not move a page in local search. They are still valid HTML and cost nothing to serve, and keeping them in step with LocalBusiness structured data means a wrong city name shows up in two places instead of one. Treat them as a supplement to schema, never a replacement.

What squirrel checks

The rule runs on every crawled page whose HTML parsed into a document, and emits one check. A page with no parsed document emits nothing at all.

• geo-meta: looks for meta[name="geo.region"], meta[name="geo.placename"], meta[name="geo.position"] and meta[name="ICBM"]. One or more present passes, with the message N geo meta tag(s) found and the names it found listed as items. None present reports at info status with the message No geo meta tags found and the value Consider adding for local businesses. Severity info.

The rule matches names, not values. A stale city name, an invalid ISO code and coordinates in the wrong hemisphere all pass. ICBM is matched with that exact uppercase spelling, so a lowercase icbm is not counted. The whole rule is skipped, with the reason shown in the report, when the site profile says the site is not a local business.

How to fix it

<meta name="geo.region" content="US-CA" />
<meta name="geo.placename" content="San Francisco" />
<meta name="geo.position" content="37.7749;-122.4194" />
<meta name="ICBM" content="37.7749, -122.4194" />

These go in <head> on location and service-area pages, not site-wide, and the values must match the address in your LocalBusiness JSON-LD.

The common false positive is a single-location business that carries the tags only on its contact page. The check is per page, so every other page reports No geo meta tags found. That result is info, not a failure, and it does not need fixing on pages that are not about a place.

Enable / disable

Disable this rule

[rules]
disable = ["local/geo-meta"]

Disable all Local SEO rules

[rules]
disable = ["local/*"]

Enable only this rule

[rules]
enable = ["local/geo-meta"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• schema/local-business: the LocalBusiness JSON-LD that search engines do read, and the place the real address belongs.
• local/nap-consistency: the same phone number or address rendered differently across the site.
• local/service-area: whether the site has dedicated location pages for these tags to sit on.
• eeat/physical-address: a postal address visible to readers, not only to parsers.

Local SEO findings ship in every audit next to the core SEO, performance and agent experience rules. See Fix SEO issues with AI for how an agent works through a report.

References

• Managing multi-regional and multilingual sites, Google Search Central
• Geo tags in HTML, IETF Internet-Draft (expired 2008)
• LocalBusiness, schema.org

Check your site

Run squirrel audit https://example.com and open the Local SEO section of the report. Every page is listed with the geo tags it carries. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.