Why did it work before publishing?

Because you were looking at a working version, served differently. File paths, image compression and page assembly all differ once live. It is the trap almost nobody anticipates.

Do I have to recheck everything on every publish?

No, only the four points in this article, and only on the public address. Ten minutes the first time, two minutes after that.

What if I find a failure after announcing the site?

Fix it, republish, then recheck on the public address before replying to anyone. The classic mistake is fixing and announcing without looking at the live result again.

What breaks the day you put your site online

Everything worked on your computer. You publish, you send the address to three people, and the replies come back: a missing image, a link going nowhere, a page that looks odd on a phone. You cannot understand how it broke when nothing changed.

The published site is not the one you were looking at. File addresses change, images travel a different path, and what worked on your machine no longer exists the same way. Four failures come back every time on day one, and all of them are checkable in ten minutes.

Why it breaks at precisely that moment

What you were looking at before publishing was not your site. It was a working version, served by a different mechanism from the one serving the final site.

Once live, several things change without you touching anything. Files get their final addresses, often different ones. Images go through a compression step and sometimes change name. Pages are assembled differently. And everything that relied on a path only valid on your computer stops existing.

Which is why the check that matters is never the one done beforehand: it is the one done on the public address, once published.

The four day-one failures

Images that no longer show. The most frequent cause. An image whose address pointed at a folder on your computer means nothing online. The text stays, the image becomes an empty frame.

Internal links going nowhere. Same mechanism. A link that worked locally now points at an address that does not exist on the published site. Often these are the menu links, so the ones everyone clicks first.

The form that no longer sends. It could work in testing and stop once live, because the sending service only allows certain addresses. Completely silent failure: the “thank you” message still appears.

The display on phones. What fitted in your computer window overflows on a narrow screen: a table too wide, an image sticking out, a menu covering the text. It is the first thing people report back, because they open the link on their phone.

The order to check in

Order matters: each step assumes the previous one is sound.

First, the public address opens. Not the preview, not the staging link: the address you are going to give people. Force a full reload so you are not looking at a cached version.

Then walk through each page looking at two things only: missing images and menu links. Three minutes for a four-page site.

Then send a real message through the form, and confirm it arrives. Including in spam.

Finally, open everything on your phone. Not by narrowing your computer window — on an actual phone, with wifi off. That is where you will see both the overflows and the real slowness.

The rule that stops you doing it forever

None of this shows before publishing, which makes the check mandatory every time. Except “every time” does not survive contact with real life.

What does survive is writing it into the instructions your tool re-reads at startup: after every publish, it checks the public address itself and reports what it sees there — not what it wrote, what it observes.

And keeping one principle for yourself: until you have opened the public address, your site is not published, it is uploaded. Those are different things, and the difference always gets paid in front of the first three people you show the link to.