Weebly website not working: down or broken

The editor shows you the draft you are working on. Visitors get the last published version at the public address, and that version can be old, unpublished, or pointed at a domain that does not reach it yet. A visitor from a search result or an ad never sees the draft. They get a page that will not open, or a page that opens with a section out of place and a button that leads nowhere. The owner, checking from the editor, sees a working site and assumes the visitor is mistaken.

• Open the public address in a private window on a phone, not the editor preview, and note whether it loads.
• Type the bare domain and the www version separately, and note which one reaches the site.
• If the page will not open, check the domain's records against the ones the site builder gave you.
• If a section is broken, open the browser console and note any script error from a custom code block.
• Click every button and link on the home page once, and note any that lead to a missing page.

A site is down for a visitor when the domain does not lead to the published site. The usual reasons are that the last change was never published, that a custom domain still points at an older host, or that its secure certificate is not ready yet. Each one leaves the visitor with a browser error instead of a page, and each is fixed outside the page itself: in the publish step or in the domain's settings. Editing the page cannot fix any of them, which is why owners who keep editing often believe nothing is wrong.

A site is broken when it loads and one part of it fails. A custom code block can throw a script error that stops the other scripts on the page, so a menu or a gallery stays frozen. A narrow phone screen can push a button under a photo, where the tap lands on the image instead. A link or a form can still point at an address from an older version of the site, so the visitor reaches a missing page, or a form that sends nowhere. Each of these is a page problem, and each shows up in the browser console or where the visitor taps.

Each run opens your public address the way a visitor does and records what comes back. The report shows whether the site loaded, a screenshot of the first screen and of the step where a visitor stopped, and any script error or failed request logged on the page. A run needs a public address, so a site that only works behind a private network cannot be tested this way. The run cannot see your domain settings or your publish history, so when a run cannot reach the site, check those settings in the builder yourself.

A domain that lapses, a DNS change, a new custom code block or a theme edit can take the site down or break one page, and none of them shows in the editor. Rerun the same simulated visitors on the public address after each of these changes, and check that the home page, the order or contact step, and each button load without a console error. A site that worked last month can still fail today.