What we check before a business website goes live
A website is ready to launch when customers can find the right information, complete the intended enquiry and understand what happens next. Here is how we tested those parts of Webora’s own website, and what to ask for when reviewing your business site.
Check where an enquiry actually goes
On 13 September 2026, we tested a clearly labelled enquiry on Webora’s live contact page. Preparing the brief did not send it. Submitting it with a reply address and the privacy acknowledgement produced a receipt, which we matched to one record in the private enquiry system. We then removed the test record.
We also tested an invalid reply address, corrected it and submitted the same brief successfully. Separate storage tests confirmed that repeating a request returned the same receipt without creating a second enquiry. These checks establish the submission path; a receipt does not mean a project has been agreed or paid for.
- Preview: the visitor is still reviewing their details.
- Submitted: the system has accepted the enquiry and returns a reference.
- Follow-up: the studio reviews the request and replies through the supplied contact method.
- Agreed or paid: the owner records the actual project outcome separately.
Keep the alternative contact route understandable
Webora’s form also offers a WhatsApp option. It prepares a message that the visitor reviews and sends in WhatsApp. Opening that link is not confirmation that the message was sent. The telephone link likewise opens the device’s calling application; it does not establish that a conversation happened.
Before launching your own site, ask the developer to demonstrate an incomplete form, a valid submission and the recovery path when a submission cannot be confirmed. Check that the visitor keeps their details and has a useful next step. Ask who reviews incoming enquiries; an inbox needs a person or an agreed follow-up process.
Verify privacy choices in the working journey
In our live test, declining optional measurement left the event count at zero through enquiry preparation and submission. Allowing it recorded the test page visit, a chat-opening action and a loading measurement. Withdrawing that choice stopped a further chat opening from adding an event. We removed the identified test measurements afterwards.
The website keeps enquiry details separate from optional measurement. It does not include chat text, form contents, full referring URLs or query strings in those events. For your own project, agree the information you actually need, where it is held, who can access it and how it is removed. Optional measurement gives an incomplete picture because visitors can decline it.
Measure loading before choosing a fix
Earlier recorded mobile Lighthouse runs on 13 September 2026 reported performance scores of 68 and 98 during work on fonts and chat loading. A later run that day reported 100 for performance, accessibility, best practices and SEO. Its largest contentful paint was 1.50 seconds, total blocking time was 70 milliseconds and cumulative layout shift was 0. The dated reports are linked below.
We reduced the two initially downloaded font files from 128,120 to 55,196 bytes, preserved the required font weights, prioritised the main image and removed its entrance animation. Chat-panel styling loads when the assistant is opened. These changes reduced initial work while retaining the visual design and customer journey.
The later report used Lighthouse 13.4.1, an emulated Moto G Power and a simulated slow 4G connection for an initial page load. These are individual lab runs, not a controlled experiment, a permanent score or real-user Core Web Vitals. They do not prove a ranking improvement or predict every visitor’s experience; field data needs a sufficient sample over time.
Review public pages and the handover
Our automated checks inspect published-page structure, titles, descriptions, canonical URLs, sitemap entries, working internal links and invalid-page handling. They also check the separation between the appointment demonstration and a real enquiry. A sitemap submission helps a search engine discover URLs; it does not confirm that every page has been indexed.
For your business, the final review should include current services, approved photographs, accurate contact details, the agreed booking destination and written arrangements for the domain, hosting and support. Keep a record of what was tested and what still depends on a third-party account or your team’s process.
Webora’s £400 package is based on six to seven agreed pages and the functionality in your written scope. Use this checklist to ask specific questions before approval and to understand what the handover covers.
Keep this comparison handy
| Check | Useful demonstration | What it confirms |
|---|---|---|
| Enquiry delivery | A labelled test request and a matching inbox record | The request reached the agreed destination |
| Retry and recovery | A repeated request and a recoverable error | Duplicates are handled and the visitor has a next step |
| Privacy choices | Decline, allow and withdraw optional measurement | The website follows the selected preference |
| Mobile loading | A dated lab report with device and test conditions | Performance in that particular test |
| Search setup | Rendered metadata, sitemap and indexing reports | Technical setup and the actual indexing state |
| Ongoing responsibility | Named inbox owner and written hosting/support scope | Who maintains the site and follows up |