An owner sits at a laptop with a new site open, ready to approve it. The home page looks sharp, the colors are right, and the approve button is one click away.
Before that click, ask the builder to run the Lighthouse audit and show you the report, then to check the pages at phone size. A site is ready once it has passed both.
A laptop approval proves one screen
A site that looks right on your laptop has passed one test, on one screen, in one browser. Picture a customer on a small phone, one hand free, standing in a driveway. We wrote about this in test your site on phones before it ships: a site approved on a laptop should also be tested at phone sizes in more than one real browser engine before launch.
- Looks right on the laptop.
- Looks right on your phone.
- On a customer's small phone, the call button is gone.
- Your Business
Laptop approved
Looks right
- Your Business
Your phone
Looks right
An illustration of one page on three screens. On the smallest, a bar covers the call button.
The call button can sit fine on the big screen, then hide under a bar that follows the scroll on a small phone, and the customer dials the next business on the list. The laptop check was honest, and it covered one size. That is the gap a pre-launch check closes.
Two checks, two jobs
The Lighthouse audit and the phone check answer different questions. The audit report names the pages it ran on. The phone check names the screen sizes and the browser engines. A good launch has both, and the builder shows you the proof of each before the site goes live, because a check run after launch is a post-mortem. We use Lighthouse for local performance audits before anything ships.
Lighthouse Local performance audits before anything ships.In our routine the audit gates the launch. Two other tools watch what happens after. We use Google Search Console for indexing and query data, checked on a regular cadence. We use Microsoft Clarity for session recordings and heatmaps that spot real friction on a page.
A clean report can sit beside a wrong detail somewhere else, because a passing audit says nothing about the parts of the site it never opens. We wrote about another thing that looks fine and is not, in our sitemap post: a sitemap where every page shows the same last-changed date usually means the build cannot read git history at deploy time. Open the real page on a real phone as well.
An example launch routine
- Build passes
- Phone check
- Audit report New
- Owner sign-off
- Go live
Questions to ask before you approve a site
You do not need to read the report to hold a builder to it. Ask four plain questions: was the audit run, on what screen, in which browsers was the phone check, and what changed after it. A builder who did the work answers each in a sentence, and a vague answer tells you something too.
None of this needs a technical background. It needs the habit of asking before you approve.
-
Was the audit run? A vague answer We checked it, it was fine.
Was the audit run? A good answer A report you can open, with the date it was run. -
What screen? A vague answer It looked good.
What screen? A good answer A named phone size, including a small one. -
Which browsers for the phone check? A vague answer Chrome, I think.
Which browsers for the phone check? A good answer More than one real browser engine, named. -
What changed? A vague answer Nothing needed changing.
What changed? A good answer A short list of fixes, each page shown again after the fix.
Four questions, and what each answer sounds like.
We also like a second pair of eyes. A pre-mortem, run by someone with no stake in how the plan was built, catches framing errors before they survive into the plan, as we described in run a pre-mortem before you commit. Hand your site to a friend, on their own phone, and ask what they cannot find in ten seconds. Choose someone who has never seen the site and will say what they find. Do it before the launch, while a fix is still quick.
Who sees the site before launch
-
designer
Checks on a new, large phone
-
owner
Approves on the laptop
-
customer
Opens it on a small phone in a driveway
The one nobody asked
The designer and you each see the page on a device chosen for comfort. Sign-off by proof reaches the customer's screen too.
Sign-off by look
- Opened on one laptop
- Looks finished
- No report to read
Sign-off by proof
- Checked at phone size
- More than one browser engine
- A report you can read in a minute
Sign-off by proof takes a little longer than a glance, and the difference shows the first time a customer opens the site on a phone you never tested.
What a good report looks like
The audit report names the pages it ran on, and the phone check names the screen sizes and the browser engines. Together they should show each page, the size and the outcome, with any failure shown beside its fix. You should be able to read it in a minute. The sample below is invented to show the shape.
Example report
| Page | Size | Result |
|---|---|---|
| Home page | Small phone | Pass |
| Contact page | Small phone | Fixed failed, then fixed |
| Services page | Large phone | Pass |
A failure that got fixed is a good sign, because it means the check had teeth. Be wary of a report where nothing ever fails, and ask which browsers the phone check covered: a pass in one engine says little about another. The same goes for page coverage. A report that checked only the home page has checked one page of many, so ask for the page names. We wrote about why a warning that fires too often gets ignored in an alert that cries wolf.
When the report comes back, read two things: which pages and sizes were checked, and what was fixed. If the smallest phone size is missing, ask why. If a fix is listed, ask to see the page again after it. Five minutes of reading is a short check before launch. If the builder pushes back, that is useful information too. Keep the report. When the next builder or the next redesign comes along, it is your record of what passed.
The rule we keep
Our rule is that the audit is a gate: the builder passes it and shows you the result before the site goes live. Our web design service runs local performance audits before anything ships.
Before you approve a site
Talk to Offer before you decide anything.
You'll talk with Offer, not a sales rep. A short call, no pitch deck.
Talk to OfferThis post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.
