Wix form not loading: blank box or no box

A form built into the page loads with the page. A form from an app or an embedded frame loads from somewhere else, and that frame can be blocked by an ad blocker, a privacy setting or a cookie tool that holds back third-party content until a visitor accepts. The visitor sees an empty box with no message, and the rest of the page looks normal. Some frames never finish, so the form stays on a spinner. The editor does not show this, because it loads the frame inside your own logged-in session, so the owner sees a working form while the visitor sees nothing.

• Open the page in a private window and scroll to the form. Is there a box, a blank space or nothing?
• Open the browser console on the page. Does an error name a script or frame that failed?
• Turn on your ad blocker and reload. Does the form disappear or change?
• Accept the cookie banner, then decline it. Does the form load after each choice?
• Load the live address, not the editor preview. Does the form appear only in the preview?

A visitor who scrolls to the form sees one of three things. The first is nothing at all, so the form was never placed on that page or was hidden on the live version. The second is an empty box, which means the container loaded and the content inside it did not. The third is a spinner that keeps going, which means the form is waiting on a request that never answers. Visitors do not know these apart, so they decide the site is broken and leave. The owner has to find which of the three it is before touching the form, because each needs a different fix.

The browser console keeps a record of what failed to load. Open the live page in a private window, open the developer tools and look at the console tab while you scroll to the form. An error about a blocked frame, a script that did not load, or a cookie refused for a third-party source points at the cause. Then check the network tab for a request to the form provider that is still pending or has failed. If there is no error and no request, the form was never asked for, and the problem is in the page itself.

A simulated visitor's browser keeps the same kind of record. The report lists the failed requests and script errors on the step where the form should have appeared, so you do not have to read the whole console to find the one that matters. Compare that list with your own console from a private window. If the two lists match, the cause is on the page. If the report shows an error your console does not, the cause is in the visitor's setup, such as a blocker or a cookie rule, and the fix is in which frames you allow.

The editor loads the form inside your own logged-in session, with your cookie choices already saved and no blocker running. A visitor often arrives with none of those. They may decline the cookie banner before the form is reached, run an ad blocker, or open a copy of the page cached from before your last change. Each difference can stop the form's frame from loading while the editor keeps working. The only way to see the live page the way a visitor does is to load it in a browser a visitor would use, at the public address, with the blockers and cookie choices a visitor would make.

Each new app, embed or cookie tool you add to the page is another frame that a visitor's blocker or privacy setting can refuse. Load the live page after every change, once with the usual blockers on and once with them off, and check the form appears both times. If the form sits behind a members login, give the visitors a test account so the check reaches the form itself.