Check the website before and after launch
Make sure the important parts of a client website work, record what still needs attention and plan the checks after launch.
A finished design is not the same as a ready website
Sam has been planning ClearFlow Plumbing's redesign step by step. The pages have clear purposes. The content drafts explain the two services. Sam has reviewed titles, mobile usability, local details and the existing page addresses.
In the last lesson, Sam decided to keep all six current page addresses. There's no good reason to move them simply because the design is changing.
Now Sam has a different question:
If the new design went live, how would we know the important things actually work?
A page can look right in a preview while its contact form sends nothing. A menu can look tidy but link to the wrong place. A page can be easy to read while a search setting tells Google not to index it.
Sam needs a simple launch review: what has been prepared, what still needs checking and who can approve the next step.
Start with the work already planned
Sam opens the notes from the earlier lessons. There's no need to start another audit from scratch.
| What Sam has prepared | What must be checked before publication |
|---|---|
| ClearFlow's six-page structure | The final build uses the agreed pages and links to the right places. |
| Clearer service-page content | The owner approves the wording and any claims about the business. |
| Titles and headings | The final pages display the correct content and settings. |
| A better mobile contact layout | Buttons and links can be comfortably used on a phone. |
| A URL plan keeping existing addresses | Important pages still open at those addresses; no surprise redirects. |
| An investigation request for the water heater page | The current noindex setting is checked and any correction is separately approved and verified. |
A plan is useful, but a drafted improvement isn't a tested improvement. Sam needs evidence from the actual website before calling something complete.
Worked example: Sam's launch board
Sam organizes the outstanding work into one small board. It doesn't need to be a complicated project management system. Each row answers three questions: What's the situation? Who needs to act? What would show it's done?
| Item | Status | Next action / evidence |
|---|---|---|
| Six existing page addresses | Plan prepared | Check final build against /, /water-heater-repair, /drain-cleaning, /blog/no-hot-water-what-to-check, /about and /contact. |
| Service copy and business details | Needs owner review | Obtain approval for public wording before publication. |
| Water heater page indexing | Needs technical check | Recheck the earlier noindex finding, agree the authorized correction if still needed, then verify the outcome. |
| Mobile contact links | Needs device test | Check the water heater page's contact link on a narrow screen and confirm it is easy to tap. |
| Contact form and phone link | Needs release testing | Check the phone link and send a clearly labeled test form, confirming it reaches the intended recipient. |
| Live-site search and tracking settings | Needs final-environment check | Review intended page access, canonical URLs, sitemap and any agreed measurement setup. |
| Publication decision | Awaiting approval | Confirm scope, responsible people and how outstanding issues will be handled before an authorized launch. |
Sam hasn't found seven new website failures. Most rows are checks that haven't happened yet. That's different from saying the website is broken.
One item does deserve particular attention: the earlier review found an unintended noindex instruction on /water-heater-repair. Sam won't assume that a new layout or SEO title has fixed it. He'll ask the authorized person to inspect the current setting and follow the agreed approval process.
Sam also knows that the contact form and phone link worked during an earlier review. He still plans to test them again on the finished website. A previous result doesn't tell him whether a later build will work.
Test the route from page to inquiry
ClearFlow wants more relevant water heater repair inquiries. So Sam follows the journey a homeowner would take.
- Open the homepage on a phone. Can you reach the water heater repair page without hunting through the menu?
- Open Water heater repair. Is the service clearly explained? Can you find and use the contact options comfortably?
- Open Contact. Does the form accept the required information, show understandable messages and deliver a clearly labeled test to the intended recipient?
- Check the phone link. Does it point to the correct number and behave as expected on a phone? A tap isn't proof that someone completed a call.
Sam also checks the website with a keyboard, makes sure form fields have clear labels, and looks for layout or text that becomes difficult to use on a smaller screen.
These are practical design checks, but they're also important to the business. A website isn't helping someone inquire if the inquiry route doesn't work.
Check what search engines will find
Sam remembers two different technical ideas from earlier lessons:
- A URL: the address someone visits. ClearFlow's existing addresses should remain in place.
- An indexing instruction: a setting that can affect whether a page can appear in search results. The earlier
noindexissue needs its own review.
Before release, the team should also check that the final site's important pages work at the expected addresses, that links go to the right pages and that the intended indexing, canonical and sitemap settings fit the final website.
If the designer has used a separate preview or staging website, its private or search-blocking settings should not accidentally carry over to the public pages. A staging preview and a live website are not the same environment.
Sam's current URL plan doesn't call for any redirects. If a future change is genuinely approved, Lesson 11's redirect map becomes part of the launch test. Otherwise, there is no reason to invent a redirect just to tick a box.
Decide whether the site is ready
Sam looks at the launch board.
The content still needs the owner's approval. The water heater indexing question needs a fresh technical check and an agreed response. The mobile contact link and final inquiry journey haven't been retested.
So Sam doesn't mark the redesign ready to publish.
That doesn't mean every small issue must hold up every project. A designer should explain which problems affect an important service, visitor journey or approved requirement, and which minor tasks can be scheduled with the client's agreement.
In ClearFlow's case, Sam first asks for the missing approvals, current checks and responsible people. The owner and authorized website team can then make an informed launch decision.
A useful checklist records the decision; it doesn't grant permission to publish.
What to check once the site goes live
When a launch is approved and completed, Sam's work is not finished the moment someone clicks Publish.
He keeps two short lists.
On launch day, check the live website:
- Open the six expected page addresses and follow important internal links.
- Check the live service content, titles, navigation and mobile layout.
- Retest the contact form and phone link, including confirmation that the form message arrives where it should.
- Confirm the intended indexing settings on the live priority pages, especially the water heater repair page, and review canonical and sitemap settings where relevant.
- Confirm any approved redirects only if URLs actually changed. Check that analytics or inquiry tracking is working where it was agreed and set up.
Over the following days and weeks, review the search information:
- Use Google Search Console to see how Google discovers and indexes important pages as its information updates.
- Follow up on errors or pages that still need investigation; request a recrawl when appropriate, with the right access.
- Compare new information with the dated baseline Sam recorded earlier, without treating one day of numbers as proof of success or failure.
A working live page and a page that Google has indexed are different things. Google may need time to crawl changes, and requesting indexing doesn't guarantee an immediate result.
Lesson 13 will help Sam explain what Search Console, website sessions and inquiry records can actually tell the client.
Don't forget your own studio
Sam now looks at Cedarline's own website drafts. The studio's /services and /work pages have clearer planned content, but the drafts haven't been published.
The same checks apply before Sam updates those pages: keep the existing URLs, review the links, test mobile navigation and the actual inquiry route, and confirm the site's search settings after an authorized change.
Your turn: If you updated your studio website tomorrow, which two things would you test before calling the change complete?
You don't need a large technical report. You need a short list of checks someone will actually carry out.
Help Sam prepare for launch
Make four launch decisions for ClearFlow. After each choice, see what Sam should consider before moving ahead. You can change your answer to explore the alternatives.
Is the redesign ready?
Sam has a six-URL plan and improved page drafts. ClearFlow hasn't approved publication. The older noindex finding needs a current investigation, and the new mobile contact design still needs testing.
Prepare a website launch review
Use ClearFlow's project or a website you're working on. You don't need to complete every field now. Record the important checks, who should handle them and what would show they're done.
See Sam's completed example
- What must you check before publication?
- Confirm owner-approved wording and scope; review the final build against the six original URLs; test service navigation, narrow-screen contact links, keyboard/forms, phone link and a labeled contact-form delivery; check live-intended indexing, canonical and sitemap settings plus any agreed analytics and backup plan.
- What could prevent a responsible launch?
- Not ready to mark for release: publication approval isn't recorded; current status and authorized response to the October 20 water heater noindex finding remain open; proposed mobile tap-target improvement and final contact flow need a fresh test. Record severity and the agreed decision for each. These aren't all confirmed new failures.
- Who needs to approve or complete the work?
- Sam prepares and performs agreed design/usability checks. The ClearFlow owner approves public claims, scope and publication. An authorized developer/admin checks and implements technical settings with the required permission. Confirm actual named owners and the release decision before proceeding.
- How will you check the site immediately after launch?
- Only after an approved launch: open /, /water-heater-repair, /drain-cleaning, /blog/no-hot-water-what-to-check, /about, /contact; follow key links; test a labeled form submission with receipt confirmed and verify the phone link; inspect live robots/canonical/sitemap as appropriate. No redirects are currently planned.
- What needs checking after the first day?
- After any future launch, check current indexing information in Search Console as it updates and review problems with the authorized team. Record evidence date, the responsible person and next review. Use the September baseline later without claiming that GSC clicks, GA4 sessions and all-source inquiries are one funnel.
- Which launch checks will you use for your own studio?
- Before publishing Cedarline's /services and /work drafts, keep both addresses and test navigation/mobile and the real inquiry route. Inspect intended indexing and note what was checked.
A confident launch starts with good checks
Sam has taken ClearFlow from the first discovery questions to a practical launch review. The website plan keeps the original pages. The content and layout improvements are still drafts, and the remaining checks are now visible instead of hidden.
Before the team launches anything, Sam knows what needs an owner's decision, what needs testing and who should record the result. After a future approved launch, he also knows which live checks happen straight away and which search information may take more time.
Next part: Measure, explain and hand over
Next: Show clients what happens after launch
In Lesson 13, Sam will use the earlier September baseline to explain what Search Console, website sessions and inquiry records can tell a client, and what they cannot.