Search engines and AI assistants often cannot see your store finder. When they visit the page, your stores are not on it yet: they only appear later, on the visitor's screen. So your stores can be missing from search results and from the answers AI assistants give.

After these steps, every store finder page arrives with its stores already on it, with names, addresses and opening hours. Search engines and AI assistants can find each of your stores and show it. Your visitors see the store finder as usual.

It works with HCL Commerce 9 and IBM HTTP Server 9 or later, for a store finder already on your shop and for a new one. Most of it happens in IBM HTTP Server, the web server in front of HCL Commerce. One step needs an HCL Commerce developer. It takes five steps.

What you need

IBM HTTP Server 9 or later, as HCL Commerce 9 ships it. On an older one, such as 8.5 under WebSphere Commerce, ask Uberall before you start: some of the lines below need a newer version.

Access to your IBM HTTP Server configuration, or someone who has it

An HCL Commerce developer, for step 3

Your render token, from Uberall

Your locator key, from Uberall. If the store finder is already on your shop, it is the data-key of its snippet:

<div id="store-finder-widget" data-key="YOUR_LOCATOR_KEY"></div>

Your store finder's address: the page it is on, such as https://www.example.com/shop/en/us/Locations. Each store gets its own address under it

Which storefront you have

Open your shop in the browser, right click, and choose View page source:

• a) The source has /wcsstore/ in it: your shop runs on the JSP storefront that HCL Commerce delivers through IBM HTTP Server. This guide is for you.
• b) It does not: your shop runs on HCL's React or Next.js storefront, which renders the pages itself. Contact Uberall before you start.

If the store finder is already on your shop

After these steps, your store finder pages use only the settings saved at Uberall. What is set on the page itself no longer applies there:

• attributes on the store finder's div, other than the ones the includes repeat (step 3)
• settings your shop's scripts pass to UberallStorefinderMount or UberallStorefinderRestart, other than withoutMap

To find them, look in two places:

• The store finder's div, in the page's source: any data- attribute other than the ones the includes repeat.
• Your shop's scripts, in the page's source and in your shop's JavaScript files: calls to UberallStorefinderMount or UberallStorefinderRestart.

If you find any of these settings, send them to Uberall before you start, to be saved with your store finder. Until then, leave the page as it is: the store finder keeps working as it does today.

Your pages' title and description

Uberall gives every store finder page its own canonical link. The title, the description and the preview image for social media come from Uberall only when they are set up there:

• The store finder's main page, and its directory pages (the lists of stores by country, region or city): only what is set up at Uberall. With nothing set up, these pages have no title and no description.
• A store's page: always a title and, when the store has one, a description: the store's name and short description, unless others are set up. The image is the store's photo.

In step 3 you take your own title and description off these pages. So check with Uberall first that a title and a description are set up for your store finder, or send yours to be saved with it.

Step 1: Connect IBM HTTP Server to Uberall

These modules must be on: include, proxy, proxy_http, headers, rewrite and deflate. IBM HTTP Server ships with all of them. If one is off, turn it on in httpd.conf, as a LoadModule line like the others there.

Open the virtual host of your shop, the <VirtualHost> that serves your shop's address, and paste this inside it. Replace YOUR_RENDER_TOKEN with your token:

SSLProxyEngine on
<Location "/api/locator-fragments/">
    Require expr %{IS_SUBREQ} == 'true'
    RequestHeader set x-uberall-render-token "YOUR_RENDER_TOKEN"
    RequestHeader unset Accept-Encoding
    RequestHeader unset Cookie
    RequestHeader unset Authorization
    RequestHeader unset Proxy-Authorization
    RequestHeader unset Via
    ProxyAddHeaders Off
    ProxyPass "https://uberall.com/api/locator-fragments/" connectiontimeout=2 timeout=10
    ProxyErrorOverride On
</Location>

The token stays on your server. Visitors never see it.

IBM HTTP Server checks Uberall's certificate against the key database of this virtual host, the file its KeyFile line names. That database has to trust the usual public certificate authorities. If it was created without them, add them with IBM's key tool, then restart:

gskcapicmd -cert -populate -db /path/to/your.kdb -stashed

Requests for your shop's pages go from IBM HTTP Server to HCL Commerce through the WebSphere plugin, as the plugin's plugin-cfg.xml lists them. /api/locator-fragments/ must not be among them: if plugin-cfg.xml has <Uri Name="/*"/>, ask whoever runs your servers to list your shop's paths instead, such as /shop/* and /wcsstore/*.

Step 2: Turn on includes for the store finder page

In the same <VirtualHost> as step 1, paste this. Replace the address with your store finder's address, without the domain:

<LocationMatch "^/shop/en/us/Locations$">
    Options +IncludesNOEXEC
    SetOutputFilter INFLATE;INCLUDES;DEFLATE
    SSIErrorMsg "<!-- -->"
    Header unset X-Robots-Tag
    Header always unset X-Robots-Tag
</LocationMatch>

What the lines do:

• SetOutputFilter INFLATE;INCLUDES;DEFLATE runs the includes of step 3 in this page. INFLATE unpacks the page when HCL Commerce sends it compressed: IBM HTTP Server cannot run the includes in a compressed page. DEFLATE compresses it again for browsers that accept it. A later <Location> for the same address with its own SetOutputFilter would replace this one, so paste it below those.
• The two X-Robots-Tag lines let search engines index these pages. Many shops send X-Robots-Tag: noindex on every page. Without these lines, search engines would leave your store finder out, with its stores in it or not.

To check whether your shop sends it: open any of your shop's pages, open the browser's developer tools, Network, reload, click the page's request, and look for x-robots-tag under Response Headers. A CDN in front of your shop, such as Akamai or Cloudflare, can send it too: then it has to leave out the store finder's addresses as well.

Step 3: Put the store finder on its page

This step is for your HCL Commerce developer. The store finder page, as HCL Commerce delivers it, needs the includes and the store finder snippet shown below. Replace YOUR_LOCATOR_KEY with your locator key, in all three places.

<head>
  <!--#config errmsg=" " -->
  <!-- ... your head, without its own title, canonical, description and og: tags ... -->
  <!--#include virtual="/api/locator-fragments/head?key=YOUR_LOCATOR_KEY&path=$REQUEST_URI" -->
</head>
<body>
  <!-- ... -->
  <div id="store-finder-widget" data-key="YOUR_LOCATOR_KEY">
    <!--#include virtual="/api/locator-fragments/body?key=YOUR_LOCATOR_KEY&path=$REQUEST_URI" -->
  </div>
  <script src="https://locator.uberall.com/locator-assets/storeFinderWidget-v2.js"></script>
</body>

The config line goes first in <head>. It keeps an error message off the page when the store finder content does not arrive.

The first include goes just before </head>. The second goes inside the store finder's div. Keep path=$REQUEST_URI at the end of each line.

This is what has to be true of the page:

• The lines arrive in the page exactly as shown. They are HTML comments. A JSP passes them on as they are. An editor that drops or escapes comments does not.
• The head lines come from the page's JSP, and only on the store finder page. If the page writes an empty <title> or an empty description today, leave those out there.
• The body line goes inside the store finder's div, wherever the div comes from: the page's JSP, or the content of an e-Marketing Spot in Management Center.
• The script comes from locator.uberall.com, as shown, not from a copy on your own server.

To check it before step 5, open the page, choose View page source, and search for #include. You should find both lines exactly as above.

On the store finder page, your shop must not add its own canonical link, og:url or og:type tag: Uberall always sends them. With two canonical links, search engines may ignore both, or take yours, which is the same address for every store. Leave out your own title, description and other Open Graph tags there too, once they are set up at Uberall (see above).

The store finder's address comes from what is set up at Uberall. Check with Uberall that it is set up, and without #!: the server only sees the part of an address before #. To use another address on this page, set it on the snippet and on the includes (below).

Where the store finder's div comes from

The div has to be in the page's HTML as HCL Commerce delivers it, so the include can go inside it. To find out where yours comes from, open the store finder page, choose View page source (not the browser's inspector), and search for store-finder-widget:

• a) You find the div: it is in the page's HTML. Keep it, once its settings are at Uberall (the section above), and add the include inside it. If the source shows Content_UI.jspf or ContentRecommendation around it, it comes from an e-Marketing Spot's content in Management Center: add the include there.
• b) You do not find it: your shop's JavaScript adds the div once the page has loaded. Put the div into the page's HTML instead, with only the include inside it, as shown above, and remove the code that adds it. Keep the code that loads the script, if it waits for the visitor's consent first.

The snippet and the includes must match

These attributes of the snippet are also parameters of both includes. Whatever the snippet sets, the includes must set too, with the same value, before &path=:

With data-language="el", data-countries="GR" and data-widgetoriginurl="https://www.example.com/shop/el/gr/Locations" on the snippet, the first include reads:

<!--#include virtual="/api/locator-fragments/head?key=YOUR_LOCATOR_KEY&lang=el&countries=GR&widgetOriginUrl=https://www.example.com/shop/el/gr/Locations&path=$REQUEST_URI" -->

If your page loads storeFinderWidget-v2-withoutMap.js, or starts the store finder with withoutMap: true, add withoutMap=true to both includes too, before &path=.

If they differ, search engines get a page built with the values of the includes, and your visitors' browsers build the page again with the values of the snippet.

Step 4: Send every store's address to the store finder page

Each store's page lives at an address under the store finder. IBM HTTP Server has to answer all of them with the store finder page. It does that inside the server: the address in the browser stays exactly as it is, and nothing redirects.

To find out which addresses your stores have, open one of your stores in the store finder and look at the address bar:

a) /shop/en/us/Locations/l/berlin/...:

RewriteEngine on
RewriteRule ^/shop/en/us/Locations/(l|s)(/|$) /shop/en/us/Locations [PT,L]

b) /shop/en/us/Locations#!/l/berlin/..., with #!: your stores' addresses become real paths under the store finder's address, without #!. The main page's address stays. Google ignores everything after #, so nothing that ranks today changes. Ask Uberall to set up your store finder's address without #!, then use the rule of a).

In the rule, replace both addresses with your store finder's address, without the domain.

The rule sends the store finder's own addresses to its page: /l with its store and directory pages, and /s with its searches. If a custom directory route or custom store addresses are set up for your store finder at Uberall, they need a rule of their own.

Put it in the same <VirtualHost>, above your other RewriteRules: it ends the rewriting for these addresses. If the <VirtualHost> has RewriteEngine on already, leave out that line.

Step 5: Deploy and check

On each IBM HTTP Server, check the configuration and restart it:

bin/apachectl -t && bin/apachectl -k graceful

Then deploy the store finder page from step 3 as you usually deploy your shop.

Open your store finder in the browser, right click, and choose View page source. Search the source for __ubSfSsr. If you find it, it works.

Search the same source for <title and rel="canonical". Each should appear exactly once. If one appears twice, your head still has its own: see step 3. If <title is missing, the store finder has no title set up at Uberall yet.

Then open one of your stores and copy its address into a new tab. The store's page should open, and its response headers should have no x-robots-tag.

More than one store finder on the shop

Each store finder has its own render token, and the <Location> from step 1 sends one. So the second store finder gets a <Location> of its own. Paste a copy of the one from step 1 below it, with two changes:

• its address: <Location "/api/locator-fragments-2/"> instead of <Location "/api/locator-fragments/">
• its token: the second store finder's token

Keep the ProxyPass line as it is. Do not paste the first one twice with another token: IBM HTTP Server would send the last token for both store finders.

Then follow steps 2 to 4 for the second store finder's page, with one change: its includes start with /api/locator-fragments-2/ instead of /api/locator-fragments/.

For a third store finder, use /api/locator-fragments-3/, and so on. Each country or language of your shop with a store finder of its own counts as one.

If it does not work

When the store finder content does not arrive

The store finder keeps working in every case. If the content does not arrive, because IBM HTTP Server cannot connect to Uberall, the connection takes too long or it returns an error, the page loads without it, and the store finder appears on the visitor's screen as usual.

When changes show

A change at Uberall, to your stores or to your store finder's settings, takes a few minutes to show on these pages.

HCL Commerce's own caches add nothing to that: IBM HTTP Server runs the includes each time the page goes out. A CDN in front of your shop adds the time it keeps your pages, if it keeps them. Each store finder page in a CDN keeps the content it had when it was cached.