Wix website not displaying properly: find why

Wix lets you edit the page you see on a laptop and, separately, the version a phone shows. The editor shows the version you are working on, so an element can sit inside the screen for you and hang off the edge for a visitor with a narrow display. Unpublished changes never reach visitors, so they see the page from the last publish. An embedded block with a fixed width can also push the page wider than a phone screen, which forces sideways scrolling and clips what sits at the edge.

• Open the published address on a phone and a laptop, and note any element that is cut off or sits past the edge.
• Open the site in a private window and compare it with the editor preview, to spot changes you have not published.
• Find every custom code block and embed, and check whether it sets a fixed width wider than a phone screen.
• Check whether a cookie banner or pop-up covers the text or the button on a phone.
• One broken page points at that page. Broken everywhere points at the header, footer or site-wide code.

A visitor does not open your editor. They tap a link and get the published page in the view their device chooses: the desktop layout on a laptop, the mobile layout on a phone. Each has its own positions and sizes, so a block that looks neat on your screen can sit off the edge on the one a stranger uses. The visitor sees a headline that stops mid-word or a contact button with no room to tap, and then they leave.

Check the two views first, on the devices a stranger uses. A simulated run that opens the published address on a phone and on a laptop gives you a screenshot of each view, and the step where a visitor stopped if they could not reach the next page. If the phone view is clipped and the laptop view is fine, the fault is in the mobile layout, and you can fix it without touching the desktop design.

Some faults are changes that were never published. The editor saves each change, so the owner sees the new version every time. Visitors see the version from the last publish, plus whatever copy their browser still holds. If the page looks right in the editor and wrong at the address, publish first, then reload in a private window before you debug the layout.

Your own browser keeps a copy of the page too, so a fix can look broken for a while after a publish. Test the published address in a private window with no saved data, and compare it with the view you have been checking. It tells you whether the problem is the page or the copy your browser is holding.

Custom code and embedded blocks are the usual cause of a layout that breaks on one device only. An embed with a fixed width, a frame for a map or a booking widget, or a script that changes the page height can push the layout wider than a phone screen. Look at each embed on the phone view and check whether it is wider than the screen or covers the content around it. Remove or hide one embed at a time, publish, and test again.

A slow booking widget or map can push the content down while it loads. A simulated visitor records the same break from the browser's side: the request that failed or ran slow, the step where it happened, a screenshot and any script error logged there. It does not read your Wix settings, so it cannot say which embed caused the break. You find that by removing them one at a time, and the run then shows whether the step came back.

A new booking widget or a banner added to the header can push a layout off the edge, and an edit on one view can leave the other as it was. After each change, publish, then open the published address on a phone and a laptop in a private window and check every page the change touches. The second look catches the break before a campaign sends traffic to it.