What Should You Check After a New Website Goes Live?

After a new website goes live, check three things: that it works for real visitors, that search engines can find it, and that you control it. On launch day, focus on the address, HTTPS, forms, phone links, mobile layouts, search-blocking settings, redirects, and email. In the first week, set up or confirm Search Console, analytics, social previews, and a basic accessibility check. In the first month, look at indexing, email authentication, backups, monitoring, and who owns each account.

You do not need to be technical to do most of this. You need a phone, a laptop, time set aside for launch checks, and the willingness to click everything.

Launch day: a suggested sequence

The address and HTTPS

Type your domain four ways: with and without "www," and with "http://" and "https://". All four should end up at the same secure address, without a certificate warning. Google "strongly recommends using HTTPS for your site to protect your users' security and privacy" (Search Console Help, HTTPS report).

Pages, navigation, and mobile layouts

Open every page in the menu on a phone and on a computer. Look for broken images, overlapping text, buttons that are hard to tap, and menus that do not open. Tap every link in the header and footer. Wild Logic's website ownership checklist suggests opening important URLs on desktop and mobile and testing "navigation with a keyboard, forms, downloads, redirects from replaced pages, HTTPS, and access to the production administration tools."

Forms, booking, and phone links

Submit every form with a clearly labeled test message and follow it all the way to where it should land: the inbox, the CRM, or the scheduling tool. Check the confirmation message the visitor sees and any automatic reply they receive. Use a sandbox or a clearly labeled test booking; avoid triggering a real charge or taking a real customer's slot. Tap every phone number on a phone to confirm it dials. Forms can break at launch if the settings from the test site did not carry over.

Search visibility switches

Sites are often hidden from search engines while they are being built. That setting has to come off at launch. Two things to confirm with whoever built the site:

• No noindex on pages you want found. A noindex rule tells Google not to index a page. Google notes that for noindex to work, the page must not be blocked by robots.txt, otherwise the crawler "will never see the noindex rule" (Block Search indexing with noindex).
• robots.txt is not blocking the site. Visit yourdomain.com/robots.txt. Google explains that robots.txt manages crawler access and "is not a mechanism for keeping a web page out of Google" (Introduction to robots.txt). A leftover rule that blocks everything is an easy launch mistake to miss.

Wild Logic's website redesign guide lists this as a launch step: "Check that staging restrictions are removed from the production pages intended for search."

Redirects from old pages

If you replaced an older site, try a few old page addresses, especially ones people bookmarked or that appear in search results. Each should land on the closest matching new page. Google advises against sending many old URLs to one unrelated page like the homepage, which "can confuse users and might be treated as a soft 404 error," and recommends keeping redirects "generally at least 1 year" (Site moves with URL changes). Permanent (301 or 308) redirects tell Google the new address should replace the old one (Redirects and Google Search).

Email still works

If the launch involved DNS changes, send and receive a test email from your business address, and check that form notifications and booking confirmations arrive and are not landing in spam. DNS controls both your website and your email, so a website change can affect mail if records are removed or edited by mistake.

First week

Search Console and your sitemap

Google Search Console is a free tool that shows how Google sees your site. Make sure it is set up in an account your business controls. A Domain property covers every version of your domain (www, non-www, http, https) and is verified through a DNS record (Add a website property).

Submit your sitemap there, but keep expectations realistic. Google says "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site" (Build and submit a sitemap). The URL Inspection tool lets you check a specific page, run a live test, and request indexing (URL Inspection Tool).

Titles, descriptions, and canonicals

Search for your business name and look at how your pages appear. Each page should have its own descriptive title (Google title link guidance). Ask your developer to confirm that canonical URLs point to the intended preferred pages, including any deliberate duplicate-page handling. Google lists redirects and rel="canonical" as strong signals and warns against giving conflicting canonical signals (How to specify a canonical URL).

Social previews

Paste your homepage and a service page link into a text message or a social post draft (without posting). The preview should show the right title, a sensible image, and your domain. These previews come from Open Graph tags; the protocol's four required properties are og:title, og:type, og:image, and og:url (The Open Graph protocol).

Analytics and key events

If you use analytics, confirm it is recording visits on the live domain, not the test site. Then decide which actions matter most, such as a form submission or a booking. Google Analytics calls these key events: "an event that measures an action that's particularly important to the success of your business" (About key events). Also confirm your consent settings match what your privacy policy says.

Accessibility spot checks

The W3C's Easy Checks are designed for people without technical training. Try a few: tab through a page with the keyboard and watch for a visible focus outline, zoom text to 200 percent, check that images have sensible text alternatives, and make sure form fields have labels and clear error messages. W3C is candid about the limit: "A web page could seem to pass these checks, yet still have significant accessibility barriers." A spot check finds obvious problems. It does not certify a site.

Integrations

Check each connected tool: booking, CRM, payments, chat, email signup, maps, and reviews widgets. Confirm data arrives in the right account and notifications go to the right person.

First month

Indexing and errors

Look at Search Console's page indexing and HTTPS reports. Pages you expect to be found should be indexed over time, and errors should be explained. Wild Logic's redesign guide suggests checking "Search Console after launch for crawl errors and unexpected canonical choices." New pages can take time to appear, so look for patterns rather than reacting to one day.

Email authentication: SPF, DKIM, and DMARC

SPF, DKIM, and DMARC help receiving servers check that mail really comes from systems allowed to send for your domain; they do not prove the sender is trustworthy. Gmail's email sender guidelines require every sender to "set up SPF or DKIM email authentication," and require SPF, DKIM, and DMARC for senders of more than 5,000 messages a day to Gmail accounts. Google Workspace explains that DMARC "tells receiving email servers what action to take on messages sent from your domain that don't pass SPF or DKIM authentication," and that SPF and/or DKIM must be set up first (Set up DMARC). Include every service that sends email for you, like your booking tool or form service.

Backups you have actually restored

Ask where the site's backups live, how often they run, who owns the storage, and when a restore was last tested. CISA lists "website and operational databases" among business data to back up and recommends testing backup procedures so you can restore data (CISA, Back Up Business Data). Wild Logic's checklist adds a useful warning: "A repository alone may not contain the live site's content or database."

Monitoring and who responds

Decide who notices when something breaks. Options range from an automated uptime alert to a person checking forms on a schedule. The important part is writing down who gets the alert and who fixes the problem. If you have a maintenance plan, read exactly what it includes.

Account ownership

Before the launch energy fades, confirm that your business, not a person who might leave, controls the domain registrar, DNS, hosting, Search Console, analytics, email, and the site's admin panel. Check the domain renewal date. ICANN warns that an expired domain can be lost "possibly for good" (Renewing Domain Names). Use individual accounts. Turn on multifactor authentication, starting with admin accounts, as CISA recommends. In Google Analytics, make sure someone at your business holds the Administrator role, since that role controls who else has access (Google Analytics Help).

Printable checklist

Next step

Print the table and work through the launch-day rows first. For the account questions, Wild Logic's website ownership checklist gives a detailed record you can fill in with any provider.