The new website goes live on a Tuesday. It looks great, the team is proud, and everyone moves on. Three weeks later the phone is quieter than usual, and someone searches for the business and finds a “page not found” where the old services page used to be. Google is still sending people to addresses that no longer exist.

A launch is the moment your site is most likely to lose search traffic, and also the moment you have the most control over it. Most of that control lives in Google Search Console, a free tool from Google that shows how the search engine sees your site. Here is how we spend the first week after every launch.

Set up the right kind of property

Search Console offers two ways to add a site. A URL-prefix property covers one exact version of your address, such as the https version with www. A Domain property covers everything at once: http and https, with and without www, and every subdomain.

Use a Domain property. It is verified once with a DNS TXT record, a short line of text added where your domain’s settings live. After that, every version of your site reports in one place, so you never miss a problem because it showed up on the version you were not watching.

One warning: never delete that verification record later. It looks like clutter to anyone tidying up DNS, and removing it can cost you access to your own data.

Map every old address before launch

This step happens before the new site goes live, and it is the one that matters most. Make a complete list of every page the old site had. Two sources together get you there:

The old sitemap. Most sites publish one, and it lists the pages the old platform knew about.
A crawl of the old site. A crawling tool follows every link the way a search engine does. On the sites we rebuild, it regularly finds pages that were linked from menus or posts but never listed in the sitemap.

Then give every old address a new home with a permanent (301) redirect. A few rules keep this clean:

Send each old page to its closest match, not to the home page.
Make it one hop. An old address should land on its final page directly, not bounce through two redirects.
If your host treats /services and /services/ as different addresses, redirect both.

When an old page truly has no equivalent, such as a leftover test page from a previous platform, it is fine to let it return a “not found” error.

Submit the sitemap and request indexing

Once the site is live, submit the new sitemap in Search Console. Do not panic if the status reads “Couldn’t fetch” right after you submit it. That is normal before Google’s first visit, and it usually clears on its own.

Next, use URL Inspection to request indexing for the handful of pages that matter most: the home page, your main service pages and the contact page. Google limits how many of these requests you can make each day, so spend them on the pages that bring in business. Asking again for a page you already submitted does not move it up the queue.

Know what is noise and what is a problem

Over the following days, the Page indexing report fills in. Some of what it shows looks alarming and is exactly right.

Expected noise:

Old addresses listed as “Page with redirect.” That means your redirects are working. Do not click “Validate fix” on these. Validation only passes when the pages stop redirecting, which is the opposite of what you want.
Old junk addresses showing as 404. Leftovers from a previous platform, with no equivalent page, are fine to leave as not found.

Real problems worth fixing:

Important pages marked “Crawled, currently not indexed.” Google visited and chose not to include them. Look at whether the page is thin, duplicated elsewhere or hard to reach from the rest of the site.
Wrong canonical tags. A canonical tag tells search engines which version of a page is the real one. If it points at the wrong address, Google may ignore the page you care about.
Pages blocked by robots.txt or carrying a noindex tag. These are often left over from the staging copy, where blocking search engines was correct. On the live site, they quietly hide pages from search.

Keep the preview copies out of search

Most new sites have a staging or preview copy where changes are tested. Those copies should be noindexed so search engines skip them, and their canonical tags should point at your real domain. Otherwise a test address can end up competing with the live site in search results.

The tricky part is the handoff. The setting that keeps staging out of search must not travel to the live site, and the live site’s settings must not be loosened on staging. Check both on launch day.

Do not forget the other search engines

Google is not the only one. Bing Webmaster Tools is free, and it can import your site straight from Search Console, so setup takes a few minutes. Bing’s results also feed other services, so it is worth the small effort.

If your host supports IndexNow, turn it on. It lets your site tell participating search engines, including Bing, when a page is added or changed, instead of waiting for them to notice. Google does not use IndexNow, so the sitemap and Search Console remain the way to reach it.

After the first week

By the end of the first week, the urgent work is done: redirects tested, sitemap accepted, key pages requested and the reports read once with a clear head. From there, a monthly look at the Page indexing report catches most problems early. We cover the rest of that ongoing work in your website after launch.

If you have a launch coming up, or one that did not go the way you hoped, our search engine optimization team can map the old site, set up Search Console and watch the reports for you.