Improve

The owner has signed off, and today the site goes live on the shop's own domain. That domain already does other jobs: it carries the shop's email, and old links point at it. Going live means moving the website without breaking any of them.

Everything here runs on this computer: this file stands in for the domain's settings, and a local server plays both hosts. Two records send the website to the old host. Two say where the shop's mail goes, and one says who may send it. Before you change anything, save a copy of the whole list. If something breaks, the copy is how you put it back.

Then change only the two web records, to the values the new host gives you: the domain's address, and www. Compare with the copy. Two lines changed. The mail lines are exactly as they were. One trap. Some hosts offer to take over the domain's name servers, these two lines. New name servers start empty, so copy the mail records across first, or the shop's email stops arriving.

Now ask the domain, the way a mail server would. Same two mail servers, same order, same sending rule. And the website's address is the new host. Each answer can be remembered for an hour here. Until then, some visitors, and your own computer, may still see the old site. Check from a phone off wifi before you call it broken.

The host then gets a certificate for the domain, usually within minutes. Check it: plain http redirects to https, and the certificate names this exact domain. Here it's from a stand-in on this computer; on the real address, the browser shows no warning.

Next, old addresses. The old site's menu was a picture, at its own address. On the new host, that address is not found. So write a redirect map: every address that used to work, and where it goes now. The menu picture goes to today's bread, the page that does its job now. The www name, the host's own address and the review link all go to the domain. Make each one a 301, a permanent redirect, so browsers and search engines carry links and results across. Then ask every old address for its answer. Don't skip the host's own address. It serves the same site, so without a redirect it competes with your domain in search.

The old host still shows the old site at its own address, with the wrong hours. Keep a copy, then take it down. Here, that means moving it off the stand-in host, into the archive. Now that address answers not found.

Now run the go-live gate on the real address. Five lines pass. Four fail, the ones people forget: the live site still tells search engines to stay away. Don't fix that page by page. Flip one switch to live and rebuild. The noindex tag and header go, every page gets its own address, and a sitemap is written. The build also sets the share picture, with its full live address. Get that right before anyone shares the link, because chat apps often keep the first card they see.

Then run the whole gate again, from the top. Every line passes, on the real address. Look for yourself in a fresh private window, since your own browser remembers the old site. The new hours are there. Sign it with your name, the date and the version that passed. The shop's email still arrives, and every old link lands somewhere real.

Move only what the website needs, keep everything else, and prove it on the live address.

Most sites get analytics the same way. Someone pastes a tag in on launch day, and six months later there's a dashboard full of numbers that nobody has asked a single question of.

So do it in the other order. Before launch, write down what the site's owner actually needs to know. Then track only what answers it. A number nobody will act on still costs something. It takes setup time, it asks the visitor for data, and it adds noise around the numbers you do care about.

Here's the section for the bakery. Its brief names one action: order bread ahead for pickup. So the owner's questions are about that. How many orders ahead come in each week? How many loaves sell out? How many people still call to ask the hours? Each question gets the step that answers it, and only the first needs analytics. Sold-out loaves come from the daily bread list, which the owner already edits each morning. The calls come from a tally the owner keeps by the phone. And there's a line saying who reads this and when, because a question nobody reads is decoration.

Most analytics tools record page views without being asked. On top of those, count a few milestones on the way to the action. Order started. Order sent, counted only once the order has actually been received, so a form that failed doesn't count as an order. If your tool can record that from the server, use it. Then stop. Twenty events with no question attached is how a dashboard stops being read.

Then the rule that doesn't bend: nothing personal goes in. Google's rules for its own analytics forbid anything that could identify a person, and name email addresses and phone numbers. They also say page addresses and titles are where it leaks most often, so look at what the order confirmation page puts in its address. Most tools let you rewrite or drop an event before it leaves the browser. Use that to strip anything personal first.

Next, take yourself out of the numbers. Before launch you'll load the site a hundred times, and so will the owner. Every analytics tool has a way to leave those visits out, by marking your browsers or by address. Use the one its documents describe, and watch it on a few visits before you rely on it. Some tools never process visits a filter has excluded, so a filter set up wrong loses data you can't get back.

Now check the plan, because it decides what's possible. Some plans count page views and nothing else, so check that custom events are included at all. Check how many events a month the plan allows, and what happens when they run out: some tools simply stop collecting. Check how far back the reports reach. Then write the limits into the file with the date you checked, so nobody designs a measurement the plan can't take.

Last, read what the tool you chose says it stores: whether it sets cookies, how it tells one visitor from another, and how long it keeps that. That's a claim about one tool, from its maker, so the file links to the tool's own privacy page instead of repeating it. Whether the site needs a consent banner is a legal question for someone qualified, and the answer can change the moment you add a second tool.

Write the questions before the tracking. Count only what answers them, nothing personal.

Launch day is the most carefully a site will ever be checked. Then someone edits a page, a photo goes up at full size, a template changes, and nobody runs the gate again.

Nobody publishes a routine for after launch, so build one. Every check from your pre-send gate goes on one of three triggers: after each change goes live, every month, or when a particular thing changes. Add the checks launch day didn't need: software updates, renewals, and whether the order form still delivers. Once a check has a trigger, nobody has to remember that it exists. They only have to notice the trigger, and many triggers can be automated.

After each change, let a machine do it. An automated check that runs on every change can load the pages a few times and fail when a result crosses a line you set. That line is a budget. Take it from Google's good thresholds, the ones from the speed lesson: two and a half seconds for the largest content to appear, and point one for layout shift. Keep the search for leftover confirm markers here too, and a link check, because both break quietly. With no automated pipeline, run the same checks by hand against the same budget.

Here's that budget written as a settings file for one widely used checker. It asserts two numbers, and 'error' means crossing either one fails the change. It takes the median of several runs, because speed results vary from run to run. And it keeps the reports in a folder on your machine instead of at a public link. The tool demo sets it up step by step. Whatever runs it, a budget is a lab number. It tells you a change made things worse, which is its job here. It can't tell you what real visitors felt.

Monthly is for what only time shows. Read the search results one page at a time. Look at real visitors' speed: Google groups similar pages and labels each group good, needs improvement or poor, from the last twenty-eight days of Chrome data. Send a test order, marked as a test, and see it arrive, because a form can stop delivering without anyone noticing. Install the updates the site's software needs, and look for anything renewing soon, the domain above all. Then check the person named on the routine is still the right one.

Most small sites will look for that speed data and find nothing, and that's expected. Chrome's data only includes pages that are publicly indexable and get enough visitors, and Google doesn't publish the threshold. It only counts Chrome users who share usage statistics and sync their history, and nothing from Chrome on iPhones. So no data means neither good nor bad. Record it as no field data, and lean on the lab budget and a test on a real phone.

The third trigger is change. Some checks are too slow or too human to run every time, but they're cheap once you know what moved. Edited copy, prices or hours means the claims list and the marker search again. At the bakery, the owner is the one who knows when the hours change. A new page means the whole pre-send gate, as if it were a launch. A change to the layout, the fonts or the images means every screen width again and a speed check, because those changes reach every page at once.

Write the routine into the handover file, with a name beside each part, and get each yes in writing. Here's the bakery's. The owner edits the bread list and the hours herself, so she does the monthly read. Her nephew builds websites, so he's called for anything structural and runs the checks after it. The first monthly read is on the second of November. A routine without a name on it stops the month you move on to the next client.

Put every check on a trigger and a person who agreed. Expect no field data on small sites.

A site you can't rebuild isn't backed up. So list what the site is made of, keep a copy of each part that you've actually checked, and try the way back from a bad release before you need it.

Five things make this site. The code and its history. The words: the page, the manuscript and the brief. The images, and their originals from before the grading. The domain's records, which here belong to AllWeb, not to me. And who holds each account: the host is mine, the domain is AllWeb's.

Copy each part somewhere else, and leave out the environment file, so no keys travel with it. Two hundred and fifty-nine files. Then check the copy against what's live: the page, the styles and the script are the same, byte for byte. A copy you haven't checked is a hope, not a backup.

Now the way back. The host keeps a list of deployments, newest first, and the newest production one is live. If a release goes wrong, an earlier one can be put back in front, from the host's dashboard or its command line, with no rebuild. Here I only list them. Nothing on the live site changes.

The second way: undo the change itself. On a copy under version control, the practice change is the latest save. Revert makes a new save that undoes it, so the history keeps both. Compare with the backup: the same again. The next publish would carry the fix.

Write it into the routine: each part, where its copy lives, how often, and when you last checked it. Then both ways back, and the day you tried them.

Keep a checked copy of every part, and try the way back before you need it.

On launch day every claim on the site can be true. A year later the opening hours have changed, a teacher has left, and the page still says 'new this spring'.

Claims go out of date at different speeds, and you can predict which ones. Prices change. People leave. Opening hours move with the seasons. Awards and memberships have years attached, and some lapse. And any word that points at time, like new, recent, latest or this year, starts going wrong on the day you publish it. Those are the claims to watch.

The claims list you built before launch already holds each claim, its status and its source. Add one more column: the date someone last checked the claim against that source. Without it, a claim checked last week and a claim checked two years ago look exactly the same, and that's how a stale one stays up.

Here are three rows from a fictional studio's claims list. Each now has a checked date and a review rule. For the price, the trigger is the studio's price list changing. For the teacher, it's any change of staff. 'New' gets an expiry date, because new can't stay true forever, and on that date the word comes off or the sentence gets rewritten.

Triggers matter because sources change without telling you. When the price list changes, search the claims list for every claim that cites it, and mark each one stale. Then re-check it, reword it to what the new source supports, or take it down. Only then does it get a new date. A stale mark in the file is fine for a day. On the live page, the claim is simply wrong.

Search thoroughly, because one source turns up in more places than you'd guess. At the bakery, one price is on Today's bread, on the order page, and in the file that builds both. Your coding agent can run that search across every file in seconds. Ask it to list each claim that cites the source, then check its list against the live pages yourself.

Good records work the same way. Each claim says what kind of claim it is, what it rests on and when it was last checked. Where nobody has checked, the record says so instead of filling the gap.

You'll be offered a shortcut, sometimes by an agent: change the date on a page so it looks fresh. Google lists that as a warning sign, changing the date of pages to make them seem fresh when the content hasn't substantially changed. It also says adding or removing lots of content to seem fresh won't help. So the date follows the work. If a page shows 'Last updated', Google's byline guidance says to label it clearly and keep the visible date and the structured-data date the same.

So the claims list now runs on two kinds of timing. Triggers fire when something changes, and the owner usually knows first, so ask them to tell you: a new price, a new person, new hours. Expiry dates fire on their own. Put a monthly look at the expiry column into the check routine from the last lesson, and nothing time-bound outlives its date.

Date every claim when you check it. When a source changes, mark what depends on it stale, and never move a date without changing the words.

After launch, everyone has ideas for the site. Make five of them in one week and the numbers will move, and you'll never know which change did it, or whether any of them did.

So change one thing at a time, set up so you can tell what happened. Start from evidence, not a hunch: a question the numbers answer, the monthly search read, something a customer said. Write the hypothesis down. Make the one change. Compare a window before with a window after. Then record what you decided, including when the answer is 'we don't know'.

GOV.UK's data community teaches a format worth borrowing: if, then, because. Here it is for the bakery. On a phone, the big Order ahead button sits below the queue photo. So: if the button moves above the photo on phones, then more regulars will order ahead, because they order on their phones in the morning and may not scroll that far. Then one primary metric, orders ahead per week, chosen before the change goes live. Choose the metric afterwards and you'll always find one that went up. The change reverses Design's photo-first rule on phones, so it goes in the decision notes with its date.

An A/B test splits visitors at random between two versions, and it's the strongest way to know. It also needs a lot of visitors. A sample-size calculator tells you how many. You enter how often visitors do the thing now and the smallest change you'd care about, and it gives the number each version needs. If a site really has that traffic, run the test in a proper testing tool and use its statistics.

Here's the arithmetic, with invented numbers. Say two thousand visits a month reach a page and two percent do the thing you want. Even to detect a jump from two to three percent, which is a big one, the standard sample-size formula at the usual settings asks for more than three thousand visitors on each version. Split two thousand a month in half and one test takes over three months, with the season changing underneath it. Put your own numbers into a calculator. For most small sites the honest answer is no test, and the bakery's plan is a before and after.

A before-and-after window is weaker evidence, so say so, because other things change at the same time: the season, a newsletter, a competitor. Keep the two windows the same length and made of full weeks. GOV.UK suggests running even a proper test for at least a full week, to cover differences between days. Never use launch week as your before, because it's never a normal week. The bakery went live on 21 October, so its before window is the four full weeks after launch week. The change goes live on 23 November, dated in the log, and the after window is the four full weeks from then.

Sometimes the after window looks like the before, or the difference is tiny next to the normal wobble from week to week. That's a result too. GOV.UK makes the point that a properly designed test teaches you something whether or not there's a clear winner. Write 'no clear effect'. Decide whether the change stays for some other reason, because it reads more clearly, say. Then stop. Don't go through ten other metrics looking for one that moved.

The bakery's result isn't in yet, and nobody should guess it. So here's a finished entry from a fictional pottery studio, with made-up figures. Customers kept emailing to ask when the next class ran, so the studio moved the next date and price near the top of its class page. The entry gives the evidence, the metric, the two windows, and then a reading in plain words that admits what else happened. A newsletter went out during the after window, so the rise is encouraging and unproven. The decision is to keep the change and look again later. Someone reading this next year can see what you changed and how sure you were.

One change, a hypothesis first, a fair before and after, and a log of how sure you are.

The usual handover is an email: the site’s live, the login details are below, call if there’s a problem. A year later the domain’s renewal notice goes to the builder’s inbox, and the owner hears her site is down from a customer.

So hand over a pack, not a password. The accounts, in the owner’s name. A routine she can follow without you. A page that says what to call someone for, and who. Then one run-through, with her hands on the phone.

Start with the accounts. Everything the site depends on belongs to the business: the domain, the host, the inbox orders arrive in, the analytics and the code. Each one is in the bakery’s name, and the owner can log in to every one. If you’re the only one who can log in, the business doesn’t own its site. You do.

The bottom of the list says where renewals go: her card and her email, so no notice lands in your inbox. And notice what isn’t in the file: passwords. They live in her password manager. A document gets forwarded, printed and copied, and a password in it is out of anyone’s control. Then she logs in to each account, on her own phone, while you watch. A login nobody has tried isn’t a handover. Once she’s in everywhere, take yourself off, unless an agreement says you stay.

Next, the routine, written for her, not for you. Short lines, in her words, each one something she can do from her phone. Every morning, the bread list. When the hours or a price change, that one line, then a look at the page. On the first Monday, the month’s three numbers, a test order, and the renewal emails.

Make it a list she can tick. The ticks stay when she closes the page and comes back, and each list starts fresh when its time comes round: the morning list each day, the monthly list on the first. Here’s that tested: a tick on the second of November survives a reload, and the list is empty again on the first of December.

Then hand her the phone. She runs the morning routine herself while you watch, and you don’t touch it. Where she hesitates, the guide is wrong, so rewrite that line in her words, there and then.

Last, a short page on when to call, and who. At the bakery it’s the owner’s nephew, who builds websites: a new page, a change to the layout or the order form, or the site not loading. Everything in her routine, she does herself. If a builder stays on call, put it in a short agreement: what’s included, how fast they answer, and how either side ends it.

Accounts in her name, a routine she can tick, and a page that says who to call.

The project isn't finished until you've written down what you'd keep doing. Two short documents close it: the decision log, and the case study.

Each decision-log entry has four parts. What you tried. The problem you hit. What you learned. And the rule you're now testing. This one is from the redesign: one grade for every photo, not forty hand edits. Write the rule as a test, so the next project can prove it wrong. Here's a second: one display size, measured in the tightest frame. Write three to five while you still remember why.

Then the case study, on one page. Say first that it was speculative. The brief in a line, then three decisions and what each changed. Then before and after, each number with its tool and date. These two came from different tools, so the page says so. Write it as improvements, so AllWeb would be glad to read it.

Before anyone reads it, find every number in its source. The old page's weight, in the audit from the fifth of October. The redesign's, in the check from the first of November. And the nineteen demo links, in the link check.

Write down what you'd keep doing, and give every number in the story its source.