Go to app

Sites & snippet

Troubleshooting

If your site's status stays on Awaiting connection or shows Blocked, the snippet is almost always being held back by another tool on your site. The two most common causes are performance plugins and content-security policies, and both are quick to fix. This page also explains what a Stale status means and includes a Safari-specific note on variant persistence.

Start with a connection check

Before changing anything, open the site's Overview and choose Check now. The result tells you whether the snippet is missing, present but blocked, or unreachable, which points you straight at the fix below. See Verify your connection for what each result means.

Performance & caching plugins

Optimizers that defer, combine or minify JavaScript can stop the snippet from running in time. The adfit snippet already carries attributes that ask these tools to leave it alone (for example data-no-defer, data-no-optimize and data-cfasync="false"), but some tools need an explicit exclusion as well.

  • WP Rocket: add the adfit script to Excluded JavaScript files so it isn't delayed or combined. The exclusion pattern /s/ covers the snippet and everything it loads.
  • Autoptimize / LiteSpeed / Cloudflare Rocket Loader: exclude the adfit script from script optimization or deferral if your status shows Blocked.
  • After changing a plugin setting, clear your site's cache, then run the connection check again.

Keep the snippet in the <head>

Make sure the snippet stays in the <head> after any plugin runs. Some plugins move scripts to the footer, which can cause a flash of the original content before adfit personalizes the page.

Content-security policy (CSP)

Some sites add a content-security policy: a security header that controls which servers the browser is allowed to talk to. If your site sets one, the browser may block the snippet from connecting to adfit even though the code is installed correctly.

How to spot it

The tell-tale sign: the manual connection check says The snippet is on your page, but the status never flips to Connected on its own. That's because the server-side check can still read your page, but the automatic detection ping from the visitor's browser is being blocked by your policy.

How to fix it

Allow the adfit snippet host, cdn.adfit.io (the same host shown in your embed code's preconnect line), in your policy. You need it in two directives:

  • script-src: so the browser can load the snippet.
  • connect-src: so the snippet can send adfit its signal and personalize the page.

Serving the snippet from your own subdomain instead? See If you use a custom domain below: you allow your subdomain, plus cdn.adfit.io for the built-in fallback.

Allow the inline bootstrap

The embed code also contains one tiny inline script: the bootstrap that prevents a flash of your original content before adfit personalizes the page. If your policy doesn't allow inline scripts (no unsafe-inline), add adfit's bootstrap hash to script-src. The same hash works for every site:

sha256-NjfKR7RRnyNsRD/jESyiZSiaj8py8awVmAx1L68Zs0Q=

Putting it together, a policy that allows adfit looks like this (add these hosts and the hash to your existing directives; don't replace your whole policy):

script-src 'self' https://cdn.adfit.io 'sha256-NjfKR7RRnyNsRD/jESyiZSiaj8py8awVmAx1L68Zs0Q=';
connect-src 'self' https://cdn.adfit.io;

If you use a custom domain

If your snippet is served from your own subdomain (see Custom domain), your embed code points at that subdomain instead of cdn.adfit.io, and it contains a second tiny inline script: a fallback that loads the snippet from cdn.adfit.io if your custom domain ever stops serving it. A strict policy then needs three things:

  • Your custom subdomain (the host shown in your embed code's preconnect line) in script-src and connect-src.
  • https://cdn.adfit.io in script-src and connect-src as well, so the fallback can take over when it's needed.
  • The fallback's own hash in script-src next to the bootstrap hash above (again, only if your policy doesn't allow inline scripts):
sha256-0SjqdiMkKRnJZk5h15Te+qvF9ZvKQvcurI7G+mbc588=

For a site at example.com serving the snippet from metrics.example.com, the directives look like this:

script-src 'self' https://metrics.example.com https://cdn.adfit.io 'sha256-NjfKR7RRnyNsRD/jESyiZSiaj8py8awVmAx1L68Zs0Q=' 'sha256-0SjqdiMkKRnJZk5h15Te+qvF9ZvKQvcurI7G+mbc588=';
connect-src 'self' https://metrics.example.com https://cdn.adfit.io;

If you leave the fallback out

Nothing breaks. Without the cdn.adfit.io entries and the fallback hash, the fallback simply stays inactive: while your custom domain is down, your pages show their original content, and personalization resumes once the domain recovers.

If a flash of original content comes back

These hashes cover the current snippet. If adfit ships an update that changes one of the inline scripts, its hash changes with it, and the update reaches installed sites within about a minute. If you pinned the hashes in a strict policy and a brief flash of your original content reappears after an update, copy the current values from this page into your script-src again. Sites that allow inline scripts don't need to do anything.

Personalizing images from other domains

If your personalizations swap in images hosted somewhere other than your own site, also allow those image hosts in your img-src directive so the browser can load them.

Without the whitelist, only the manual check works

If you can't add cdn.adfit.io to connect-src right away, automatic detection won't work and you'll need to rely on the manual connection check. Whitelisting the host restores automatic detection and live personalization.

Ad blockers

adfit is built to coexist with ad blockers. Everything the snippet needs (the script itself, its configuration, and its signals) is served from a single adfit host under short, neutral /s/ paths: no third-party tracker domains, no advertising endpoints, and nothing that identifies your visitors. Most content blockers leave this kind of delivery alone.

One honest limit remains: the default host, cdn.adfit.io, is shared by all adfit customers, so a particularly aggressive block list could still add it. The most resistant option is serving the snippet from a subdomain of your own site with a custom domain (available on the Growth plan and up). The snippet then loads as part of your own site's traffic, which block lists rarely target.

If a visitor blocks the snippet anyway

Your page still works. Visitors who block the snippet simply see your original content: adfit always fails open to the page you published.

The status shows Stale

Stale means adfit connected to your site before but hasn't received a signal from it for about a day. That's usually not a fault: a site with little traffic can simply go a day without a visit.

  • The status recovers on its own: as soon as the snippet reports a visit again, it flips back to Connected. The same goes for Blocked and Error.
  • To confirm right away, open your site once in a new browser tab. The status usually updates within a few seconds.
  • If the status stays Stale even after you visit, the snippet may have been removed or blocked. Run the connection check and follow its result, using the sections above.

Safari visitors lose their variant

If returning Safari visitors stop seeing their variant after about a week even though Variant persistence is set to Persistent, that's Safari's tracking protection at work, not a fault in your setup. See Browser support for details.

Still stuck?

If the snippet is installed in the <head>, excluded from your performance plugins, and the adfit host is whitelisted in your CSP, but the status still won't connect, get in touch through the support channel on your plan. See Plans & pricing for what's included.