how do i launch my website without breaking it?

web · 2026-09-19 · 3 min

launching is not pressing publish. it is the hour when the domain starts pointing at the new site, the certificate is valid, the forms arrive, and the old addresses still work. most launches go wrong in that hour, not in the design.

the sequence i use is boring on purpose: finish the content, test on a preview url, lower the dns ttl a day before, switch, then watch.

before the switch

every page has a title, a description and one clear action. the contact form sends to an address you actually read. images are compressed and have alt text. the site works on a phone, on mobile data, not only on your office wifi.

then the boring list: a backup of the old site, a copy of the current dns records, and a redirect map. every old url that mattered gets a 301 to its new equivalent. this is the step people skip and the one that costs search traffic.

the switch

if the site is on netlify or vercel, you add the domain in the dashboard and change two records at the dns provider. on shared hosting, you point the a record at the new server. either way, lower the ttl to something short a day before, so a mistake is fixed in minutes instead of hours.

after the change, check four things in this order: the https certificate, the www and non-www versions, the redirects, and one form submission. then add the domain to google search console and submit the sitemap.

the first week

do not touch the design for seven days. watch search console for crawl errors, watch the form for real messages, and ask three customers to find one thing on the site. launch week is for evidence, not taste.

the work that starts after the switch has its own list, and it is longer than the launch itself: what happens after you publish.

the last hour before it goes live

the launch sequence is in the post. this is the list i run in the final hour, with the site already answering on the real domain.

dns. check the a record and the cname at the provider, not in the builder's dashboard. then check from a phone on mobile data, because your laptop may still be holding the old address in cache.

ssl. the padlock is not enough. open both the www and the non-www version and look for a mixed content warning or a redirect loop. if one of the two works and the other does not, the certificate or the redirect is half configured.

the form. send a real message, from a real phone, to the real inbox, and open the spam folder. then send a second one and check that the confirmation arrives. one successful test is a coincidence.

404. type a nonsense address after the domain. a default server page is a small embarrassment; a blank screen looks like the site is broken. one line of copy and a link home is enough.

analytics. open the realtime report and load the page yourself. if you appear, the tag works. if not, it is missing or blocked.

robots.txt. open it and read it. a leftover block-all from the staging setup is the quietest way to disappear from search for a month.

sitemap. open it, click two urls, confirm they load. a sitemap listing old addresses is worse than none.

backup. download one and open the archive. an untested backup is a hope.

faq

how long does dns take to propagate?

usually minutes, sometimes a few hours, depending on the ttl you set before. if it has been a day and the old site still appears, the records are wrong, not slow.

will i lose my google rankings?

not if the content moved and the old urls redirect. you lose rankings when the new site drops pages or changes addresses without a 301.

should i delete the old site immediately?

keep it for a month, read-only, behind a backup. deleting it the same day removes your only fallback.

how do i publish my website?

point the domain, wait for the certificate, then test in this order: dns from a phone, https on both www and non-www, a real form submission, a nonsense address for the 404, analytics in realtime, robots.txt and the sitemap. download a backup before you start. the click takes a minute, the checks take an hour.