Klaviyo embed form not showing up: live page

The editor shows the form on its own. On the live site the form depends on the page. The site script must load there, the address must match the rule that says where the form may appear, and the trigger must fire for the reader's device. A reader on a phone cannot move a cursor toward the top of the screen, so a form that waits for exit intent never opens for them. A reader already counted as having seen the form may be held back by a frequency rule. None of these throws an error, so the owner sees a normal page with nothing on it.

• The site script: is the Klaviyo snippet on the page the reader opened, not only the home page?
• The page rule: does the form's targeting include the exact address the reader is on?
• The trigger: a timer, a scroll or exit intent, and whether it can fire on a phone.
• Frequency and exclusions: a rule that hides the form from someone who saw it or already joined.
• Blockers: ad blockers and privacy settings can stop the script before the form loads.

The form is drawn by a script that runs on your site, and that script must be present on every page where the form should appear. A script added to the home page and one template can leave the blog, the pricing page or a landing page built from another template without it. A reader on an uncovered page sees a normal article with no form, and a reader on a covered page sees the form. Check the page source for the script before you touch the form settings, because settings cannot help a page that never loads the script.

Then compare the live address with the form's page rule. A rule written for the blog section may not match a campaign page under another path, or a translated copy of an article. The test makes this visible: a simulated reader opens the exact address you send people to, not the home page, and records whether the form drew. A missing form on one address and a working form on another points to the rule, not the script.

Once the script is present, the trigger decides when the form appears. A time delay or a scroll works on a phone. Exit intent needs the cursor to leave the top of the window, which a phone reader cannot do, so a form set only to exit intent is invisible on every phone. An owner who tests with a mouse on a laptop sees it appear, and assumes the phone version works too.

Frequency and exclusions hide the form for a different reason. A rule that shows the form once per reader can keep it hidden from any browser that already counted, and an exclusion for people already on the list hides it from someone who joined earlier. Your own browser is the worst test for this, since it has seen the form many times. Use a fresh private window with no signup for the first-visit view, then reload the page to see whether it stays hidden as intended.

A simulated reader arrives at the address, reads down the page the way a reader would, and waits for the form. The report says whether the form drew, the screenshot at the point where it should have appeared, and any failed request the page made on the way. A missing form is recorded as missing, with the page and the step, which narrows the cause to the script, the rule or the trigger.

Run the same readers again after each change to the script, the page rule or the trigger, on a phone and a laptop, because the phone run is the one that catches exit intent. The run does not read your Klaviyo account, so it cannot show profile counts or whether a reader who saw the form then signed up. Use Klaviyo's reports for those numbers, and this run for why the form never appeared.

A new landing page built from another template, a redesigned blog or a site move can drop the script from pages that worked last month. The form still shows in the editor and vanishes on the live address. Rerun the same readers on each new address after a template change, on a phone and a laptop, before a campaign sends people there.