What to check on a website in the week after launch

Why the first week deserves its own plan

Launch day is busy and full of relief. The site is live, the client is pleased, and everyone moves on. That is exactly when small faults slip through. A redirect missed in the rush, a form that stops sending after a plugin update, a tracking tag that never made it from the staging site to the live one.

None of these is visible in a quick look at the home page. They show up later as a drop in inquiries nobody can explain. A short, deliberate check in the first week catches nearly all of them while they are still cheap to fix.

The plan below assumes the build itself was checked before launch, as our guide to what a white-label website build should include before launch describes. The first week is about confirming that what was checked on staging also holds on the live site.

Launch day

On the day the site goes live, run these checks on the live domain, on a phone and on a laptop:

• every page in the main navigation loads, with no errors or missing images
• each contact form sends a real test inquiry, and it arrives in the inbox someone actually reads
• the phone number on every page rings the right line when tapped
• the site loads over https, and the http and www versions redirect to the main address
• old addresses from the previous site redirect to the right new pages; test at least the ten that brought the most visits

Write down each check and its result. If something fails, fix it the same day and test again.

Day two

The day after launch, look at the measurement side:

1. Open Analytics and confirm that visits from launch day were recorded.
2. Find yesterday's test inquiry as a key event. If it is missing, the tracking is not finished.
3. In Search Console, confirm the property is verified for the live domain and submit the sitemap.
4. Use the URL inspection tool on the home page and two main service pages. Check that Google can fetch them and that they are not blocked or marked noindex.

That last check matters more than it sounds. Sites built on a staging server are often set to discourage search engines, and that setting is easy to carry across by mistake.

Days three to five

By midweek, Search Console starts to show what Google is finding. It is too early for performance trends, but not too early for problems. Look for:

• Crawl errors on old addresses. If Search Console reports old pages returning not found, the redirect list has gaps.
• Pages with redirect. Some are expected after a rebuild. Check that each one points to a sensible page rather than the home page.
• Server errors. Even a few suggest hosting or plugin problems that should be looked at now.

At the same time, ask the client whether inquiries are arriving as normal. They will often notice a quiet inbox before any report does.

The end of the week

By day seven, do a slower review of the whole site as a visitor would. Read each service page on a phone. Check that images are sharp, text is readable without zooming, and the call to action is easy to find. Look at page speed for the main templates using Google's PageSpeed Insights, and note anything that is clearly slow.

Then compare the first week's visits and inquiries with a typical week on the old site. A new site often settles over several weeks as Google recrawls it, so small changes are normal. A sharp drop in inquiries is not, and points back to forms, tracking or redirects.

Who does what during the week

A launch week goes more smoothly when each check has a named owner. On a typical project the split looks like this:

• The builder owns redirects, server errors, page speed and anything that needs a change to the site itself.
• The person responsible for search owns Search Console, the sitemap and the URL inspection checks.
• The person responsible for reporting owns Analytics, key events and the comparison with the old site.
• The client confirms that inquiries arrive and that the phone is ringing as normal.

On a small project one person may hold three of these roles. That is fine, as long as each check is written down with a name beside it. When an agency works with a delivery partner, agree before launch which side runs each check and who tells the client the result.

What not to change in the first week

The first week is for checking, not for redesigning. Resist the urge to rename pages, change addresses or rewrite headings because a stakeholder has had second thoughts. Every change of address needs a new redirect, and every change made in a hurry is another thing to test.

Keep a list of requested changes instead. Most can wait until the second or third week, once the site has settled and Google has recrawled the main pages. Fix faults immediately; schedule improvements.

The same applies to tracking. If inquiries look low in the first few days, check that the tracking works before changing any copy. A form that is not being counted looks exactly like a page that is not persuading anyone, and the fixes are completely different.

A worked example

A small accountancy practice launches a new site on a Monday. Launch day checks pass. On Tuesday, the test inquiry is in the inbox but not in Analytics: the form's success event was set up on staging and not copied across. It is fixed by lunchtime.

On Thursday, Search Console shows a handful of old blog addresses returning not found. They were left out of the redirect list because they were thought to be unimportant, but two of them had steady visits. Redirects are added to the nearest new articles.

By Friday the client mentions that inquiries look normal. The week ends with a short note: what was checked, what was fixed and what to watch next month. That note becomes the first entry in the site's record.

What to check first

If you only have time for four checks in the first week, make them these: a real test inquiry arrives and is counted, the top old addresses redirect correctly, Google can fetch the main pages, and the client confirms inquiries are coming in. Everything else can wait a few days. Those four cannot, because each one decides whether the new site is quietly losing work. Our website redesign work includes this week as standard, because it is where most of a rebuild's risk sits.