Articlesoperations

The checker is on your page and nothing happens

The embedded checker draws nothing, refuses to answer, or says every check failed. Each symptom has one usual cause, and all three are fixable in the app.

The embeddable checker has three failure looks, and each one points at a different place. Before reading further: the embed screen in the app has a Check the install button that fetches your page and tells you which of these you have, by name.

Nothing appears at all

The script did not run or could not find its mount point. In order:

  1. Both lines of the snippet are needed. The div with the token is where the checker draws; the script tag is what draws it. A page with only one of them shows nothing and logs nothing.
  2. The token in the page must match the token in the app. Site builders that “clean up” HTML sometimes strip data attributes. View source on the published page, not in the editor, and look for data-maplogics-widget.
  3. The widget must be answering. A widget with an empty allowed-sites list, or one switched off, mounts nothing worth mounting. The embed screen’s status column says which yours is.

It appears, but every check says it failed

Open the browser console on your page. If you see a line saying the token is not allowed on your site’s address, that is the whole story: the widget only answers on the sites you listed. Add the exact origin, including whether it is www., on the embed screen and save. A wildcard like https://*.yoursite.com covers subdomains, and covers them only with the dot: it never matches lookalike domains.

If there is no console line, the checks are timing out or your page’s security policy is blocking the request. The checker calls one API host; if your site sets a Content-Security-Policy, its connect-src needs to allow https://api.maplogics.com.

It answers, but says no to addresses you cover

That is not an install problem: the checker gives the same answers your API gives, from your published configuration. Read the reason code in the decision log, and see the companion article on the four kinds of no. The one install-shaped cause worth checking: if the widget is set to ask about one specific service, an address covered for a different service answers as not available. The service is a setting on the widget, not on the page.

What the checker will never do

It never sets cookies, never loads fonts, never adds requests to your page beyond its own API calls, and never sends the visitor’s address to your analytics or ours. The answer event it fires on your page carries the outcome, so you can count yeses and nos, and deliberately nothing else.