WordPress popup not working: find the trigger

Many popups wait for an event before they open: a time delay, a scroll past a set point, a click, or an exit intent. Exit intent fires when the mouse leaves the top of the window. A phone has no mouse, so a popup set to exit intent stays hidden for every phone visitor. A delay or scroll trigger can be too late as well. A reader who finishes a short article and leaves never reaches the point where the box would open. The owner sees the popup in the editor and assumes it will open for everyone.

• Open the page in a private window with no saved cookies, then wait for the trigger you set.
• Note the trigger type. Exit intent needs a mouse to leave the window, so it cannot fire on a phone.
• Check the display rules for this page's address, the device type and first or repeat visitors.
• Check the close control at phone width. A popup taller than the screen can push its own X out of reach.
• Clear the cache and load the page again. An old stored copy can hold last month's trigger settings.

The first failure is the trigger, which is the event that tells the popup to open. Many builders offer a time delay, a scroll point, a button click or exit intent. A new visitor who skims a page on a phone may never scroll far enough for a scroll trigger, and never moves a mouse for an exit trigger. Pick the trigger by asking how a stranger on a phone reaches the moment you want to interrupt.

The second failure is a display rule. Rules can limit a popup to certain addresses, device types, or visitors who have not seen it before. A rule written for the landing page can quietly leave out a blog post, or a rule set to every page can open the box somewhere you never meant it to appear. The third is the cache. A stored copy of the page can carry the trigger settings from before your last edit, so the editor and the live page disagree. Check each rule against the address of the page where the popup is missing.

Many popups remember that a visitor closed them or already saw them. That memory lives in the visitor's browser, so your own browser keeps it after the first view, and the popup looks broken whenever you test there. A returning visitor gets the same silence for the period you set. A private window starts with no memory, so it shows what a new visitor sees. Keep one private window for this check, and clear it between runs so each run starts from nothing.

A popup that appears and then traps the visitor usually has a layout fault. On a phone the box can be taller than the screen, so its X sits above the top edge where a thumb cannot reach it. A header or cookie notice with a higher layer can cover the close button, and a setting can stop taps on the dimmed background from closing the box. Each of these leaves a visitor with no way out except the back button. Look at the close control at phone width, and note whether the page behind the popup still scrolls.

A simulated visitor opens the page as a new visitor and waits for the same delay or scroll point your trigger uses. The report gives the step, a screenshot of the page where the popup should have opened, and whether the close control was in view. The run cannot read your popup settings or your caching plugin, so it cannot name the rule that caused the miss. It shows whether a new visitor on a phone saw nothing or saw a box they could not close.

Popups change quietly. A new landing page added to a rule, a changed trigger, or a theme update can switch the popup off for pages it used to cover. Run a new visitor from a page that should show the popup and from one that should not, after each change to a rule. Keep the two runs side by side so you can see which setting moved.