Where an audit looks for your address
Two of the strangest findings a local business gets are opposites of each other: no physical address found anywhere on the site, on a site whose address is at the bottom of every page, and dozens of address variations found, on a site that publishes one address identically everywhere. They have the same cause, and the second one is what the fix for the first one did.
The region most likely to hold it was the region nothing could see
Almost every content check wants the page without its furniture. Strip the navigation, the header, the footer, the sidebar and the forms, and what is left is what the page actually says — which is the right input for word counts, for readability, for whether a heading describes the text beneath it.
It is exactly the wrong input for an address. The footer is where a business puts its address. So the single region most likely to hold the thing being looked for was the one region the check could not see.
We found this on a test fixture that carried a full street address below its copy and was told, in plain English, that no physical address appeared anywhere on the site. Four markup shapes were tested afterwards, and the address survived into the stripped text in exactly one of them:
| Markup | Address visible to the check |
|---|---|
A <footer> element, page has a <main> | No |
A <footer> element, no <main> | No — stripped as boilerplate |
A plain <div> footer, page has a <main> | No — outside the main container |
A plain <div> footer, no <main> | Yes |
Read that table again. The only markup the check worked on was the least semantic version.
A site that followed the advice these very reports hand out — use
<main>, use <footer> — was the site that got the false
positive.
Then it read the whole page, and the nav became part of the address
The fix looks obvious: search the chrome too. It is the right fix, and it produced the opposite failure within one release.
Flattened page text has no punctuation between regions. A breadcrumb ends and a footer begins with nothing but a space between them, so the last words of your navigation and the first words of your address are one sentence as far as any pattern is concerned.
Address patterns work backwards from the postcode, walking through comma-separated components. Nothing in flattened text marks where a breadcrumb stops and a building name starts. So the first component came back as the breadcrumb plus the building name — and because the breadcrumb differs on every page, so did the address.
A membership organisation publishes exactly one address, identically, in the footer of every page. We told it that thirty-one address variations appeared across its site, and advised it to standardise on one exact format everywhere. It already had.
What fixed it, and what the fix cost
From flattened text you cannot tell where a building name begins. You can tell where the street line begins, because it carries the number. So the key became everything from the first comma-component that starts with a digit — or with a unit word, since "Suite", "Flat", "Floor" and "Unit" start plenty of real street lines — and leading components with neither are dropped.
That has a price, and it is worth naming rather than burying: a building name present on some pages and absent on others is no longer reported as an inconsistency. Those two forms now compare equal. That is not the mismatch this check exists for — the one that matters is a street abbreviated one way here and another way there, or two versions of the same phone number — and it was worth losing to stop telling a site with one address that it had thirty-one.
One more trap inside the fix. "Starts with a digit" is not the same as "contains a digit", and
the first version used the looser test. A breadcrumb on a not-found page reads Home 404
and contains one, which left false variations surviving on exactly the pages nobody looks at.
Position tells you where to look, not what you found
It is worth separating two questions that sound alike.
Where should a tool look? Everywhere. Excluding a region from the search is how you get told you have no address. The footer, the header and the navigation are all places real facts live.
What does the position of something tell you about it? Very little. Elsewhere we make the case that repetition separates a site's furniture from its content and position does not →, because markup is whatever the theme author chose. Both are true. Search the whole document; do not conclude much from which part of it a thing turned up in.
And the served HTML is not always where the address is
There is a third version of the same false positive, and it is the one most likely to be live right now on a site built with a drag-and-drop platform.
If the footer is drawn by JavaScript after the page loads, the address is in no document a crawler receives from the server. A roofing company whose homepage displays its address in the footer was told, as a statement of fact, that it published no address anywhere — and that finding sat third in its report.
The answer was already in the building: a sample of pages is rendered the way a browser builds them, and that text is folded in. If your own tooling reports an absence, the first question is which document it read — see how to audit a JavaScript site →.
Checking your own report
- If a tool says you have no address, look at your footer's markup. Semantic elements are correct and worth keeping; the tool is what needs fixing. Check the rendered page against the served HTML before believing either.
- If a tool reports many variations, read the variations it lists. If they share a common tail and differ only at the front, you are looking at your own navigation, not at an inconsistency.
- Count your premises before believing a count of variations. A business with several branches has several addresses on purpose, and that is not the same finding.
- Compare the site against the listing, which is the comparison that pays. The match between what you publish and what your business profile says is the thing this check is a proxy for.
The fixes that make it worse
- Moving your address out of the footer to satisfy a tool. The footer is where visitors look for it and where a search engine expects it.
- Deleting the building name because a report called it a variation. The report was reading a breadcrumb. Removing real information to quiet a false finding is the most expensive possible response to it.
- Publishing the address twice in slightly different formats so that whichever one a tool reads, it finds something. That manufactures the exact inconsistency the check exists to catch.
- Standardising a format that was already standard. Free, and it costs an afternoon.
How to pass every address check while telling nobody where you are
Put your address in an image. Every text-reading check on every tool goes quiet, because there is no text to read and none of them can tell the difference between a fact expressed in pixels and a fact that is absent. Customers cannot copy it, screen readers cannot announce it, and a search engine cannot match it against your business listing — but the report is clean. An absence finding is a statement about what the tool read, and that is worth remembering in both directions: when it is wrong about you, and when it is quiet about something it never saw.
Where this sits in an audit
The registered checks are local.nap, which compares your name, address and phone
everywhere they appear, and local.schema, which reads the structured-data version of
the same facts. For the case where a field is present but empty, see
when a field is there and still missing
→. For judging an absence finding in general, see
how to tell whether an audit tool is lying to you →.
For the map-pack signals themselves, see why your business is not in
the map pack →.
Common questions
Why does an audit say my site has no address when it is in the footer?
Because most content checks strip the navigation, header and footer before reading a page, and the footer is exactly where a business puts its address. Semantic markup makes it worse, not better: the stripping is what hides it.
Why am I told I have many address variations when I publish only one?
Because flattened page text has no punctuation between regions, so a breadcrumb runs into the footer address and the pattern reads both as one string. A different breadcrumb on every page produces a different variation on every page.
Should I move my address out of the footer?
No. The footer is where visitors look and where a search engine expects it. A tool that cannot read it is the thing that needs fixing.
Does this affect addresses drawn by JavaScript?
Yes, and more severely. If a platform draws the footer after the page loads, the address is in no document the server sent, so a check reading served HTML reports it as absent. Compare the rendered page with the served HTML.
What is the address check actually for?
Matching what your site publishes against your business listing. A street abbreviated one way in one place and another way elsewhere, or two versions of one phone number, weakens that match. A building name appearing on some pages and not others does not, which is why it is deliberately no longer reported.