Locator Upgrade – A faster, more SEO- and GEO-friendly store locator

English (US)

+ More

Table of Contents

The opportunity What you get Why now Requirement - Hashbang removal Before you start Setup overview Choose your platform What problem does this solve? What does server rendering do? Why does it matter? Does it work for an existing store finder and a new one? What is a render token? Is there one token for all of a customer's store finders? Where does the token go? Who provides the token? How often does this need to be done? Do customers need to redo it when stores change? Who on the customer side does it? Is there anything to do before starting? How does the customer know it's working?

The opportunity

We are upgrading our store locator to give customers the seamless website integration they love, paired with maximum SEO and Generative Engine Optimization (GEO) performance. Currently, because some search engine crawlers and bots from AI answer engines like GPTBot and ClaudeBot do not reliably execute JavaScript, they don’t "see" all the details on local pages. By upgrading to the next major version of the locator that pre-renders HTML directly into your websites, we close this visibility gap, ensuring every local detail is instantly incorporated by both traditional search engines and modern AI bots.

What you get

By upgrading, you get a next generation server-rendered version of the store locator. AI tools then see the same details your visitors do:

Store name, address and opening hours in the page's HTML
Directory pages that link to every location
Structured data, plus the right title, description and canonical URL on each page
The same domain, template and embed code, with no move to a hosted locator

The current (client-side-rendered) version keeps running untouched for every customer who doesn't switch. This new version has a distinct, additive endpoint — v1 and v2 operate side by side, so nothing breaks for customers who aren't ready to move.

Why now

AI tools answer from the pages they have already read. The sooner your pages are readable, the sooner answers about your stores can use your own data.

We do encourage you to upgrade as soon as possible. This new version will provide a store locator that's just as interactive, but visible to search engines and AI crawlers immediately, and noticeably lighter on the browser, since it no longer has to build the whole page in JavaScript on load.

Requirement - Hashbang removal

Server-side rendering works by having your web server request the finished HTML for the exact page being visited from Uberall, and it identifies that page from the URL path.

Anything after a hashbang (#!) never reaches your server, because browsers don’t send it, so with a URL like yourdomain.com/stores/#!/l/berlin/main-street-1/123 your server only sees /stores/ and can’t tell which location to pre-render.

Your local pages would still be built by JavaScript in the browser, which means search engines and AI crawlers would keep missing their details, the very problem this upgrade solves. Remove the hashbang first, so each local page has a clean URL like yourdomain.com/stores/l/berlin/main-street-1/123, using How to remove Hashbangs (#!) from Locator URL.

Before you start

Time: About 30 minutes for a web developer, plus testing
Access: Your web server (nginx, Apache, or LiteSpeed), your CMS, or a CDN that supports Edge Side Includes (ESI)
Environment: Set it up on staging first, then move to production

Setup overview

These steps apply to every platform. Your platform guide (below) covers steps 3 and 4 in detail.

Get your Render Token. Please contact your Account Manager for your Render Token.
Move snippet settings into the Builder. If you have data attributes, copy any data-* attributes other than data-key and data-language into your locator configuration. Once server rendering is on, the snippet ignores them.
Configure your server. Add two internal routes that forward requests to Uberall using your render token. See your platform guide.
Add two include lines to your locator page template. Your embed code stays the same. See your platform guide.
Remove duplicate head tags. On locator pages, stop your template from adding its own title, canonical, meta description, and og:* tags. Uberall supplies them.

Running one locator on several websites? Also pass each site's countries and widgetOriginUrl.

Note: Render Token and your Store Finder Key are two different keys. Store Finder Key is public, Render Token is private.

Choose your platform

Follow the setup guide for your web server or CMS:

Don't see your platform? Contact your Account Manager or Uberall Support and we'll help you get set up.

FAQ

What problem does this solve?

The store finder is built in the visitor's browser by JavaScript. When Google or an AI assistant visits the page, the stores often aren't on it yet, so individual locations can be missing from search results and AI answers.

What does server rendering do?

Your website asks Uberall for each store finder page already filled in, before the page is sent out. Every page then arrives with its stores on it: names, addresses, opening hours, page title, description and structured data (schema).

Why does it matter?

A location that search engines and AI assistants can't see can't be ranked, shown or cited. Server rendering makes each store individually discoverable, which is the foundation of local SEO and visibility in AI answers.

Does it work for an existing store finder and a new one?

Yes, both. Customers with an existing store finder have one extra check before switching (see Implementation).

What is a render token?

A password-like code from Uberall that lets the customer's website request pre-rendered store finder pages. Without it, Uberall declines the request and the store finder loads in the browser as it does today.

Is there one token for all of a customer's store finders?

No. There is one token per store finder. A customer with five store finders needs five tokens, each set up with its own store finder.

Where does the token go?

On your (customer's) server, never in the page. Each setup's guide says exactly where: for example, a settings page in WordPress or the server configuration for Apache or Nginx.

Who provides the token?

Uberall. The Account Manager will provide the token for each store locator. Customers will be able to obtain them from the UI soon. More details to come.

How often does this need to be done?

Once per store finder. After setup, it runs automatically on every page visit; there's nothing to repeat or schedule. Customers only revisit it if they add a new store finder, move it to a different page or website, or change how their site is hosted.

Do customers need to redo it when stores change?

No. Changes to stores or store finder settings at Uberall show on the pages automatically within a few minutes. If the site uses a page cache, they show once the cache refreshes the page.

Who on the customer side does it?

Whoever manages the website. For WordPress, a site administrator can usually do it alone. For Apache, Nginx, Next.js or the API, it's a developer or the team that runs the web server.

Is there anything to do before starting?

Customers with an existing store finder check for custom settings on the page itself. After the switch, only settings saved at Uberall apply, so any custom settings in the page's code (for example extra data- attributes or window.ub_ settings) must be sent to Uberall first. Until then, the store finder keeps working as it does today.

How does the customer know it's working?

View the store finder page's source in a browser and search for __ubSfSsr. If it's there, it works. Then open one store's address in a new tab: the store's page should open with the store's name as the title.

enhancement locator