Your Google Business Profile is complete, the reviews are in, the town name sits in every second heading. And your business still does not show up nearby where you expect it to.
The profile is rarely the reason. The reason is what your website says about your location — in the form a machine reads it.
Search engines do not read an address in your footer. They read markup, response times and status codes. This article shows you which technical signals count, which of them stopped working, and what you can check yourself in half an hour.
If you need the strategy first — profile, reviews, local keywords — start with Local SEO Switzerland. This piece is about the layer underneath.
Your location lives in three places, not one
Every business maintains its address in at least three places. Usually nobody knows there are three.
- In the Google Business Profile. Outside your website, maintained by you.
- Visible on the website. Footer, contact page, imprint.
- Machine-readable in the source. As structured data no visitor ever sees.
The third one is missing most often, and it is the only one understood without interpretation. An address in the footer forces Google to pull it out of running text and guess whether it belongs to you or to a partner. An address in structured data tells it.
When the three disagree, none of them wins. Google sees a business whose details do not line up, and charges the uncertainty against all three.
LocalBusiness: the fields that actually say something
Structured data for a local business is a block in your source that describes, machine-readably, what your business is, where it sits and when it is reachable. The format is JSON-LD, the type is LocalBusiness.
These fields carry weight:
| Field | What it does |
|---|---|
| name, telephone, email | The basics, spelled exactly as everywhere else |
| address | Street, postcode, town, canton and country as separate values instead of one line of text |
| geo | Latitude and longitude, so the match does not hinge on how the town name is spelled |
| openingHoursSpecification | Opening hours per weekday, with a start and an end |
| areaServed | The area you serve, which for service businesses is often larger than the location |
| sameAs | Profiles showing the same business: LinkedIn, commercial register, directories |
| hasMap | The map link you set yourself, instead of one somebody else maintains |
One detail almost everyone gets wrong: closed days. Entering Saturday as a window from 00:00 to 00:00 is meant as "closed". It also reads as "open around the clock". The clean way is to leave the day out — what is not stated counts as not open.
We do exactly that on alpeniq.ch. The schema lists Monday to Friday, the weekend is deliberately absent, and the details on the contact page come from the same source as the ones in the source code.
What does not belong in your schema
This is the uncomfortable part, because two of the most frequently recommended measures no longer do anything, and one of them can hurt.
Ratings in your own markup. An aggregateRating on your own LocalBusiness looks good in the testing tool and is still the wrong move. Google's own wording: if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other Organization markup are ineligible for the star review feature. That explicitly covers embedded third-party review widgets too.
Stars in your own source therefore produce no stars in search, only exposure. Your reviews belong in the Google Business Profile, where Google shows them anyway and where they do not come from you.
FAQ markup as a route to a rich result. Google switched off the expandable FAQ presentation in search results in May 2026, for every website. A visible FAQ block is still worth having: it answers real questions and covers search terms nobody else serves. The markup simply no longer produces a special result. Building an FAQ on that argument means working towards a metric that no longer exists.
Claims you do not keep. Opening hours that are wrong. A service area you do not serve. A company name with keywords in it. Structured data is a commitment, not ad space, and winning back a withdrawn presentation takes longer than cleaning up beforehand.
And what about AI search?
The common assumption: ship structured data and you get cited more often in AI answers. There is no solid evidence for that. An Ahrefs comparison from May 2026, covering roughly 1,900 pages against 4,000 control pages, found a slightly negative relationship for Google's AI Overviews and nothing measurable for the other answer engines.
What is evidenced sounds duller and holds up better:
- Access. Block the AI providers' crawlers and you do not appear there. That is in their own documentation, not a guess.
- Indexability. A page that is not indexed, or that forbids snippets, cannot be cited.
- Classic ranking. Pages that rank organically get pulled in more often.
- Topical coverage. Answering the question completely beats any markup.
So you build structured data for search engines and for the unambiguous identity of your business, not as a lever for AI answers. What does move visibility in AI systems is covered in our article on AI SEO in Switzerland.
NAP: one source, three outputs
NAP stands for name, address, phone. Everyone knows the details have to match everywhere. Almost nobody concludes that they should therefore be maintained in exactly one place.
The usual failure is not sloppiness, it is distribution: the phone number sits in the footer component, on the contact page, in the imprint and in the schema. Four files, four chances to update, three to forget. After the next number change one of them is stale, and nobody notices, because the four are never visible side by side.
The technically sound answer is a single source in the code that every output reads from. Change the number once and it changes everywhere.
Outside your website comes the second half. There you keep a list instead of a source:
- Google Business Profile
- Bing Places
- local.ch and search.ch
- Industry and trade association directories
- Commercial register entry
- Social media profiles
That list belongs somewhere findable, not in the head of whoever created the entries. How to build and maintain the entries themselves is in our guide to local SEO for SMEs.
Load time: local search happens on the move
Local queries come overwhelmingly from phones, often outdoors and on mobile networks. That makes load time not a comfort question but the condition for the click from the map result arriving at all.
Google names three thresholds for an experience rated as good:
- LCP under 2.5 seconds, until the largest visible element is there
- INP under 200 milliseconds, until the page responds to an input
- CLS under 0.1, how much the layout still shifts while loading
These are measured on real users, not in a lab. A number that looks fine on your machine on office Wi-Fi says nothing about the person standing in a car park. Which levers actually move load time is in our guide to website speed.
Then there is the part no metric captures: phone number as a tap-to-call link, address as a map link, form usable without zooming. Someone arriving from a local search wants to call or drive over, not read.
Crawlability: what is allowed to be fetched at all
Everything above is pointless if the page is never read. Four things decide that:
- robots.txt. A Disallow somebody set for a staging site three years ago is still in force. This is the most common silent total failure.
- Sitemap. Every location and service page belongs in it, with a change date that tells the truth.
- HTTPS and clean URLs. One address per piece of content, no parameter variants, a canonical pointing at itself.
- Firewall and bot filters. Some protection systems block crawlers without anyone configuring it. robots.txt says "allowed", the response says 403.
That last point rarely surfaces, because it is not in the files people check. It is why we list the AI crawlers individually in the robots.txt on alpeniq.ch — not because a blanket allow would be insufficient, but because an explicit list is checkable and a silent removal shows up.
Check it yourself in thirty minutes
Six steps, no tools beyond a browser and Google's free services:
- Open the source and search for LocalBusiness. No hit? Then that is the biggest lever on this list.
- Cross-read the details. Put schema, imprint, contact page and Google profile side by side and compare character by character. Abbreviations count: "St." and "Street" are two spellings.
- Check the opening hours. Is a closed day in there as a window from 00:00 to 00:00? Take it out.
- Search for aggregateRating. Found it? Remove it, for the reasons above.
- Run PageSpeed Insights on your contact page, on mobile, and look at the field data rather than only the lab score.
- Open your own robots.txt and be able to justify every Disallow line.
Getting those six right does more for your local visibility than the next article about keywords.
Conclusion
Local visibility has two halves. One is upkeep: profile, reviews, content. The other is technical, and it decides whether the upkeep lands at all.
The difference rarely comes from more measures. It comes from unambiguous details: one source for your location data, a schema that only claims what is true, a page that loads in two seconds on a phone, and access nobody closed by accident.
None of that is spectacular, and most of it is a day's work. After that, every further local SEO measure sits on a foundation instead of on sand.
If you want to know what your site says today and what is missing, we will look at it with you. How we build technical visibility is on the SEO service page; keeping it stable runs through website maintenance. The fastest way through it is a free strategy call.
Frequently Asked Questions (FAQ)
What is LocalBusiness schema?
LocalBusiness is a type from the schema.org vocabulary that lets you state your name, address, phone number, opening hours, coordinates and service area on your website in machine-readable form. The block sits in the source as JSON-LD and is invisible to visitors. It does not replace the visible address, it makes it unambiguous.
Do I need structured data if I have a Google Business Profile?
Yes, because the two describe different places. The profile describes your entry at Google, the schema describes your website. When they agree, they confirm each other. When they differ, Google has two versions and no reason to follow yours.
Can I put review stars into my own schema?
No. If a business controls the reviews about itself, its pages using LocalBusiness or Organization markup are ineligible for the star review feature. That covers embedded review widgets too. Stars in your own markup therefore produce no stars in search.
Is FAQ markup still worth anything?
Not for how you appear in search results — Google switched that presentation off in May 2026. A visible FAQ block remains useful because it answers real questions and covers search terms. The markup can stay, it just no longer justifies a measure on its own.
How fast does my website need to be for local search?
Google's stated good values are an LCP under 2.5 seconds, an INP under 200 milliseconds and a CLS under 0.1, measured on real users. Because local search happens mostly on mobile and on the move, the mobile figure is the one that counts, not the desktop score.
Does structured data help you get cited in AI answers?
There is no solid evidence for it; an Ahrefs comparison from May 2026 even found a slightly negative relationship for AI Overviews. What is evidenced: crawler access, indexability, classic ranking and complete topical coverage. You build structured data for the unambiguous identity of your business, not for AI citations.
How often should I check the technical details?
Immediately after any change to address, phone number or opening hours, and otherwise twice a year. Also after every website relaunch: that is when structured data most often disappears, because it is invisible and nobody misses it during handover.
How does ALPENIQ help with this?
We check what your site currently states machine-readably, consolidate the location data into one source, build the schema so it contains only verifiable claims, and measure load time and crawlability against real values rather than lab numbers. After that, maintenance keeps the state stable instead of letting it vanish at the next relaunch.