The first 30 days after launching a website: what to check and record

Start with availability and the complete enquiry journey. Then check important pages in search and review the first enquiries. At the end of the month, choose changes supported by specific observations. If the main action is broken, fix it immediately, whatever the date on the calendar.

Create one document with the launch date, main domain, and home, service and contact URLs in every language. List the agreed journeys: enquiries, calls, bookings or payments, but only those the website actually supports. Keep known limitations separate so they are not mistaken for new faults.

• Name the person who receives enquiries and confirms test delivery.
• Record the developer contact, the channel for reporting faults and the agreed response time.
• Note who can access Search Console and any connected analytics. Record missing tools too.
• Agree who can publish a fix and restore a working version if a change goes wrong.

Use the domain, hosting and email guide to organise account access and renewals. Service names and responsible people are enough for the check log; passwords and secret keys do not belong there.

Open the home page and main services on a phone and computer without being signed in as a developer. Check navigation, language switches, contact details and buttons. Make sure the keyboard or a fixed panel does not cover the form, the conditions are readable and images load.

Send an agreed enquiry using your own test data and a clear “Test” label. Check the on-page response, receipt in the working inbox or CRM, and the ability to reply. If the journey includes a customer receipt, check that too. A success message on screen does not by itself prove delivery.

Also test missing required fields and a repeated submission: errors should be understandable and a second click should not create confusion. The enquiry form fields and states guide explains the details. After a fix, repeat the exact journey that failed.

If you are starting paid traffic, use the landing page checklist before advertising. It also checks whether the page matches the advertisement; this monthly plan does not replace acceptance of that journey.

In your verified Search Console property, inspect the home page and key services with the URL Inspection tool. Save the status, last crawl date and Google-selected canonical URL where available. The indexed report describes the version known to Google; a live test helps assess current accessibility.

If a required URL is inaccessible or excluded by mistake, send the developer its address and exact status. Ask them to check the server response, unintended indexing restrictions, canonical and sitemap on the live domain. Private utility pages and demonstrations may be excluded deliberately; not every URL needs to be searchable.

The guide to SEO before launch covers the technical prerequisites. After a material fix, you can request another crawl, but repeated requests do not speed it up. A successful test does not guarantee indexing, and indexing does not guarantee a high ranking. Day seven is your review point, not a Google deadline.

When data is available, open the Search Console performance report to see which pages and queries receive impressions and clicks. An impression describes visibility in search; a click is a visit from the results. Neither metric is an enquiry or a sale.

Use consistent dates and filters when reviewing the data again. Look separately at searches for the company name and searches for a service: they answer different questions. For a new website, a handful of impressions or a short reporting period is not enough to judge demand or conclude that the structure is wrong.

If analytics is connected, compare the agreed events with a test enquiry. A button click, an accepted form and a received email are different events. Mark tests and account for collection limits. Without analytics, track received enquiries without guessing their source; do not calculate a conversion rate from incompatible datasets.

Ask the person who answers customers to collect recurring questions without personal information. Is the service scope clear? What about coverage, information needed for an estimate and the next step? Record the relevant page and what could be clarified.

For example, visitors may ask whether cleaning includes waste removal. This is an illustrative situation, not a result from an XEVOR client project. First clarify inclusions and exclusions on the service page and near the enquiry action. After publication, observe whether that misunderstanding becomes less common.

Use the guide to writing service page copy to work on the wording. Link from an article to the matching service where the reader understands their task, and from the service to an explanation that helps them decide. A new article should answer a distinct question rather than repeat an existing page under another keyword.

Each entry needs a date, URL or journey, observed result, customer impact, owner and follow-up check. The rows below are illustrative examples, not studio data. Remove real enquiry text and contact information from any error screenshots.

Do not close an issue just because someone says it is fixed. Repeat the action at the live URL and record the result. A publication date also helps avoid crediting a change for results collected before it went live.

• If the website or its main action fails, diagnose and fix it instead of waiting for another report.
• If key pages are not indexed, investigate the specific statuses and technical causes. Publishing more articles alone will not resolve them.
• If relevant visitors arrive but misunderstand the terms, check the content, enquiry journey and form.
• If enquiries arrive but conversations stall, review the team’s response, service fit and customer expectations.
• If data is still limited, continue observation and your audience acquisition plan. A lack of enquiries alone is not a reason for a complete redesign.

Choose a small, agreed set of changes. For each one, record the problem, intended result, publication date and verification method. Avoid changing all the copy, structure and acquisition channels at once without a record: it makes the result harder to interpret.

A plan for checks and technical fixes can be discussed as part of website maintenance. If observations point to a different set of pages or journeys, define the scope of a website redesign first. For a new project, include this period in the business website development plan before launch.

Send XEVOR your website URL and a task description: what fails, how to reproduce it and what needs to change. A short log makes the discussion more concrete. Maintenance scope, platform suitability and possible changes are agreed after reviewing the website.