What time of day should a website go live?

The principle is to pick a time when someone is around if things go wrong, not a time when nobody is watching. Plenty of teams launch in the middle of the night to minimize disruption, but if only one person is online at that hour, the vendor contact is unreachable, and the content owner is asleep, the moment you need to decide whether to roll back you are stuck. The practical arrangement is the first half of a weekday, avoiding promotional periods, the day before a holiday, and the day of an important event, with development, content, and the decision-maker all available. If the site handles transactions, also avoid the monthly billing or reconciliation peak.

Do we really need a rollback plan? It sounds like a lot of work.

Yes, and it is usually simpler than you think. A rollback plan comes down to three questions: where the complete backup of the old site is, how long it takes to put it back online, and who decides to roll back. Writing those answers down in a few lines and rehearsing them once costs very little, and it determines whether a bad moment means calmly executing an agreed procedure or improvising under pressure. One thing to watch: if the launch also changes the database structure or the URL scheme, rolling back is not just restoring files, and the data and redirect rules have to be considered alongside them.

We cannot find the new site in search after launch. Is that normal?

A newly launched address takes time for search engines to get to know again, so not being found in the short term does not necessarily mean something is broken. But a few causes should be ruled out immediately: whether the setting used during development to block search engines is still in place, whether the sitemap has been submitted, and whether old URLs redirect correctly to the new pages. Those three are the most common causes in practice, and all of them can be checked on launch day. Once you have confirmed the setup is sound, the right next step is to watch the crawl status and error pages reported by your search tools, rather than repeatedly tinkering with the content.

Website Launch Checklist: Go-Live and After

The last mile of a website project is often the messiest stretch of the whole thing. The design has been signed off, the features have been tested, and then someone asks when it goes live, which opens a long tail of details nobody remembers agreeing to own.

Launching is not one action. It is a sequence. This guide gives you a checklist you can use directly, plus what to do on the day and afterwards. Start ticking items off a week before the planned launch date rather than going looking for them that morning.

The pre-launch checklist

Content and copy

Proofread the whole site for typos and phrasing, paying particular attention to headings, button labels, and form hints
Contact details correct: phone, address, opening hours, email
No leftover test copy, placeholder images, or development-stage filler
Every image has alternative text, not only for accessibility but because search engines read it too
Prices, service descriptions, and any legally required labeling confirmed one final time by the business side

Links and forms

Every link on the site checked, with nothing pointing at a page that does not exist
Consistent behavior on whether external links open in a new window
Every form actually submitted once, confirming the notification email arrives
Where the notification goes and to whom, verified by the recipient in person rather than by trusting a success message from the system
Required-field validation, error messages, and the post-submission success screen all tested
Spam protection enabled, but not so aggressive that it blocks real visitors

SEO basics

A distinct title and description on every page, not one set shared site-wide
Clean, readable URLs with no temporary development paths left in
Sitemap generated and submitted to your search tools
The development-stage setting that blocks search engines confirmed removed. This is the single most common launch incident
For a redesign, the old-to-new redirect map tested line by line; see The Website Redesign SEO Checklist
If you use structured data, validate the format with the official tools; for the approach, see On-Site Customer Reviews and Review Schema

Speed and mobile

Use the site on a real phone, not just a narrowed browser window
Images compressed, with dimensions matching how they are actually displayed
Loading experience measured on the homepage and the main conversion pages; for metrics and acceptance criteria, see Website Speed Optimization
Third-party code inventoried, with no duplicate or retired tracking tags
Main flows tested on a slower connection

Security and backups

The whole site served over an encrypted connection, with no mixed content warnings
Admin login path, default accounts, and weak passwords all dealt with
Permissions confirmed: who can edit content, who can change settings, who can see personal data
Automatic backups enabled, and a restore actually performed once to confirm they work
System and packages updated to stable versions
For the fundamentals and the incident response sequence, see Website Security Basics for Businesses

Analytics and tracking

Analytics installed correctly, and installed only once, since duplicates distort the data
Conversion events defined: form submissions, phone-number clicks, adding your account as a friend on a messaging app
Internal traffic excluded, so your own browsing does not contaminate the data
Any advertising platform tags confirmed as well; for the setup, see A Practical Guide to GA4

Legal pages

Privacy policy and terms of service written from what you actually do, not template text
A clickable link to the policy beside every form
If you use a tracking consent mechanism, confirm the tracking scripts genuinely do not load before consent
For the drafting principles and the common mistakes, see How to Write a Website Privacy Policy

Domain, DNS, and certificates

The domain is registered in the company name, not in the personal account of a departed employee or a vendor
The renewal date is recorded and a reminder is set
The www and non-www versions both resolve to the same place
The certificate is valid and renews automatically
Email-related settings will not break when the site moves. This is the item most often overlooked during a migration
For the underlying concepts, see A Beginner’s Guide to Domains and DNS

Rollback plan

A complete backup of the old site, files and database, held separately
The rollback steps written down, with the execution time confirmed
Who has the authority to call a rollback, and that person is online on the day
If the data structure changes, confirm no data is lost after a rollback

The sequence on go-live day

Final confirmation before the switch. Run the key items on the checklist once more, particularly the search engine blocking setting, the form notifications, and the certificate. Confirm at the same time that everyone involved is online.

Execute the switch. Follow the agreed order, reporting after each step. Do not make other changes during the switch, so that causes remain distinguishable if something breaks.

Immediate verification after the switch. Open the site on different devices and networks rather than only on your own computer, which may be serving you a cached version. Confirm each item in turn: the homepage opens, the main pages open, forms submit, notification emails arrive, the admin system accepts a login, and the encrypted connection is working.

Tell the rest of the company. Only once you are satisfied, notify the sales and support teams, and make sure they know who to report problems to.

The watch period. Keep observing for a while after launch instead of packing up the moment the switch is done. For acceptance method and defect severity, see How Software Acceptance Works.

What to watch after launch

What to observe	What to look at	What a problem means
Error pages	Inaccessible pages reported by your search tools	A missed redirect or a mistyped link
Form submissions	The trend in inquiries actually received	A problem with notifications or validation
Traffic sources	Changes in organic search and direct traffic	Redirect or tracking tag problems from the migration
Load speed	Real-world loading performance on the main pages	Images or third-party code dragging it down
Server status	Error logs and resource usage	A traffic or application problem
Support reports	What customers are actually running into	Real situations the checklist did not cover

The most valuable signal usually comes from support, not from a dashboard. A customer saying “I pressed the button and nothing happened” typically surfaces a problem earlier than any monitoring tool, provided support knows who to report it to.

What to resist during the watch period is the temptation to make one more small change while you are in there. The first stretch after launch should be reserved for fixing problems, with new requests recorded and scheduled into the next cycle; for the cadence afterwards, see The Post-Launch Optimization Roadmap.

Common launch disasters

Forgetting to remove the setting that blocks search engines. Added during development so an unfinished site would not be indexed, left in place at launch, and the site stays invisible in search for a long time.

Form notifications going to an inbox nobody reads. Usually the address the vendor entered while testing, never changed back, with every inquiry disappearing into it.

The domain registered under a personal account. Discovered at renewal or transfer time, when the person who originally set it up cannot be reached.

Overwriting without a backup. After something breaks, the only option is to keep fixing forward, because going back is no longer possible.

Discovering on launch day that the content is not ready. Content is the most underestimated item of all. Agree explicitly at the start of the project who supplies it and when it lands.

The value of a good launch checklist is not how complete it is. It is that it forces the team to settle who is responsible, when each thing happens, and who to call when it does not, before going live. Most launch disasters are not technical problems. They are cases of nobody knowing whose job that was.

If your website project is approaching launch and you want to check for gaps, or you would rather walk through the launch with a team that has done it before, talk to NETVANA about your project. NETVANA’s development process runs in two-week sprints with a working demo at the end of each cycle, and once the project fee is settled the source code, design files, and documentation are transferred in full; for the detailed cadence, see the software development process.

Further reading: for the redirect detail in a redesign or migration, see The Website Redesign SEO Checklist; for how to set acceptance criteria on speed, see Website Speed Optimization; for the fundamentals of security and backups, see Website Security Basics for Businesses; for setting up tracking and conversion events, see A Practical Guide to GA4; for writing the legal pages, see How to Write a Website Privacy Policy; and for the optimization cadence after launch, see The Post-Launch Optimization Roadmap. For how environments and deployment work before go-live day, see Test, Staging, and Production Environments.