Web Design for Aqua Guard Roofing & Damp Proofing — Damp Proofing & Roofing, Kent

At a glance

What was actually wrong with the old website?

It was invisible, insecure, and it never said what the business did. Those three problems compounded each other.

The old site ran on WordPress and had thirteen URLs in its sitemap. Every one of them carried the same last-modified date, all within a couple of hours of each other, which told us it had been rebuilt in one sitting from an archived copy rather than grown over years. The footer still showed the badge of the free tool used to recover it.

More damaging: it was served over HTTP with no certificate. Chrome and Safari both put a “Not secure” warning next to the address. For a homeowner about to spend three or four thousand pounds on a damp course, that warning does real harm before they have read anything.

Then the copy. The homepage talked about “Building Your Vision”, “Sustainability” and a “Client-Centric Approach” — generic construction theme text, written in American English. Not one mention of tide marks, blown plaster, black mould or a leaking flat roof. Nine services sat buried in a nested burger menu, one of them greyed out. Roofing was a single line in the navigation despite being half the company name.

There was also a second live site on a different domain with near-identical copy, a different service structure and a different phone number. The two were competing with each other in search, and between them they put three different numbers in front of customers.

• Two live sites — competing for the same searches, with different phone numbers on each
• No SSL certificate — so both browsers displayed a security warning on arrival
• No service content — nine services hidden in a menu, none explained on the homepage
• Americanised, generic copy — “prioritize”, “utilize”, “personalized” — clearly a bought theme, not written for the business
• Roofing all but absent — half the trade, one nav link, no page of its own

Why we built the site around symptoms rather than services

Because nobody searches for “damp proofing” when they have a problem. They search for what they can see.

A homeowner in Gravesend does not know whether they have rising damp, penetrating damp or condensation. They know there is a tide mark on the wall, or black mould in the corner of a bedroom, or a patch that gets worse every time it rains. Those three things look similar and need completely different fixes — and treating the wrong one is money gone.

So the homepage opens with a row of six symptom tiles. Tide marks on the wall. Black mould in the corners. Plaster blown or bubbling. Flat roof leaking or ponding. Render cracked and staining. Basement or cellar wet. Each one is a button that opens the enquiry form pre-tagged with that symptom, so Jack can see what the person is looking at before he picks up the phone.

That decision shaped the whole site. Every service page leads with what you would see, not with the treatment name.

• Six symptom tiles — on the homepage, each routing to the enquiry form with the symptom already selected
• A “think you’ve found damp?” section — with a phone mock-up running an animated scan over real job photography, and three steps: snap it, send it, we read it
• An auto-sweeping before/after scanner — on the homepage, cycling four real jobs with technical readouts that flip from “MOISTURE: HIGH” to “NORMAL” as the line passes
• Symptom-led FAQs — on every page, several of which argue against the sale — the rising damp page states plainly that rising damp is the most over-diagnosed problem in the trade

Why we used the client’s own photography rather than stock

Because a damp proofer’s own job photos are the most persuasive asset they own, and stock images of smiling tradesmen are not.

Jack sent us roughly twenty photographs from real jobs — a flat roof stripped back to rotten decking, an elevation with cracked render, a cellar taken from bare block to a screeded floor, a wall injected and replastered. Several were shot from almost the same position before and after, which is unusual and very useful.

We built the site around those pairs. The homepage scanner and the before/after sliders on the service and location pages all use genuine work rather than illustration. The brand’s existing logo — a silver house with a blue droplet — was supplied only as a square JPEG on a dark background. We cut the house icon out of it by luminance, trimmed it to its alpha bounds and generated a full favicon set from it: .ico at 16, 32 and 48 pixels, a 180px Apple touch icon, and 192, 512 and maskable versions for Android.

• Two flagged as not theirs — two render photographs looked like supplier stock and did not match the rest of the set — we left them out rather than pass them off as the client’s work
• Logo cut out and rebuilt — keyed off its dark background by luminance so the glow survives as a soft edge rather than a hard cutout ring
• A landscape lockup — trimmed from the square original for the header, footer and drawer
• Captions on every gallery image — naming the stage of the job — “Strip · Rotten deck exposed”, “Build up · New deck and insulation”

Why we built it in static HTML rather than WordPress

Because the old site’s problems were WordPress problems, and a nine-page brochure site for a two-man trade does not need a database.

The previous site had been recovered from an archive, was carrying a plugin-era footer badge, and had no certificate. Static files on Cloudflare Pages remove the entire class of problem: nothing to patch, nothing to hack, no plugin that breaks on update, and free SSL by default.

We wrote one stylesheet as the single source of truth and a Python build step that inlines it into every page at build time, along with a compressed copy of the logo as a data URI. That means each page is self-contained and renders correctly on its own, while the design system still lives in one file that cannot drift apart.

• One stylesheet — assets/aq.css — edited once, inlined into all 24 pages by the build
• A build script with a deploy gate — which fails the build on a broken internal link, a missing image, a page that has lost its stylesheet, or any missing launch file
• An automated pre-launch audit — that renders every built page in a headless browser and checks exactly one H1, no heading level skips, no JavaScript errors, no broken images, alt text on every image, canonical present, title and description length, hero alignment, and horizontal overflow at 390px
• Launch files on every build — _redirects, _headers, robots.txt, sitemap.xml, a branded 404 and the full favicon set

How we structured the local SEO for Kent, South East London and South Essex

We matched the old site’s URLs exactly wherever we could, then built the service and location pages the old site never had.

Before touching anything we fetched the old sitemap rather than relying on its navigation. It listed thirteen URLs. Ten of them — /roofing/, /rising-damp/, /damp-proof-course/, /damp-proof-plastering/, /penetrating-damp-solutions/, /ventilation/, /colour-coatings/, /clear-coatings/, /gutter-systems/, /basement-tanking/ and /contact/ — now resolve to a real page on the same path with no redirect at all. Three had WordPress duplicate-slug suffixes and are 301’d. The site stayed on www because that is where the old one was indexed, so no legacy URL takes a hostname hop.

How we got it loading fast enough on a phone

By serving each device an image sized for that device, and by not loading anything the visitor has not scrolled to yet.

The photography came in at 8.3 MB across the site, with single files over a megabyte. We resized everything to its real display dimensions, recompressed it, and generated 480px and 960px variants of every photograph. The build then writes a srcset on each image with a sizes attribute matched to how wide that image actually renders in its own context — a gallery thumbnail at 277px is told 300px, the homepage scanner at 1,110px is told 1,120px.

The homepage scanner was the biggest single win. It holds four before/after pairs but shows one, so the other six images now hold back until their tab is opened.

PageSpeed Insights returned 97 for performance on desktop with 100 for best practices and 100 for SEO. We are not quoting a mobile figure here because it moves with the test conditions, and a number we cannot reproduce is not worth printing.

• Site photography — 8.3 MB down to 2.6 MB, originals kept out of the deploy in case a larger crop is needed later
• Mobile first load — 907 KB down to 472 KB on the homepage
• Width and height on every image — so nothing shifts as the page loads
• Hero preloaded with imagesrcset — so the browser fetches the right variant immediately rather than after layout
• CSS inlined — no render-blocking stylesheet request; the homepage is roughly 68 KB over the wire gzipped
• Layout reads cached — in the scanner and slider loops, which removed a forced reflow warning

Why we bothered with the Agentic Browsing score

Because AI assistants now read websites on behalf of customers, and a page they cannot parse is a page they cannot recommend.

Lighthouse’s Agentic Browsing check tests whether the accessibility tree is well formed — essentially, whether software can understand the structure of the page rather than just render it. The site was failing it, and the cause turned out to be three separate instances of the same mistake.

We had used aria-hidden to hide things from screen readers: the mobile navigation drawer when closed, a spam honeypot field, and the duplicated chips and review cards in the scrolling marquees. But aria-hidden does not remove anything from the keyboard focus order. So the closed drawer was hiding 32 links that a keyboard user could still tab into, which is precisely what breaks the tree.

All three now use the inert attribute instead, which removes an element from the accessibility tree and from the focus order together. We added a rule to the build gate so it fails if any aria-hidden element is focusable or contains something focusable.

• Contrast raised — the footer legal line was 3.4:1 against the dark background; it and three other muted greys now clear WCAG AA, with the footer at 8.3:1
• Every form field labelled — including the honeypot, which was the original cause of both the accessibility and the Agentic failures
• Alt text on every image — enforced by the build
• Reduced-motion respected — the scanner, marquees and scroll reveals all stop for anyone who has asked their device to reduce motion

What nearly went wrong, and how we caught it

A duplicated script left two copies of the enquiry form handler on every service page. The older one showed the customer a success message without sending anything.

It would have looked perfect. Fill the form, click submit, get a tidy confirmation. And every lead from a service page would have gone nowhere. The client would have concluded the website did not work, and he would have been right.

We found it by mocking the form endpoint in a headless browser and asserting that a network request had actually been made — rather than by filling the form and trusting the confirmation panel, which is what a manual check would have done. Two related faults surfaced in the same test: the sending function was scoped inside a closure the second handler could not reach, and the build step was rewriting the placeholder inside the JavaScript that checks whether the form key is configured, so the check always failed.

Two other things were caught the same way. Adding width and height attributes to every image — done to stop layout shift — overrode the CSS aspect-ratio rules, so portrait photographs rendered at full height and stretched cards to well over a thousand pixels tall. And an early redirect file contained two rules with absolute URLs in them, which Cloudflare Pages does not accept; the assets uploaded fine and the deployment then stalled at the processing step with no error message.

• Every fix locked into the gate — the build now fails on over-tall images, on aria-hidden elements that are focusable, and on a form page missing its access key
• Regressions tested by reverting them — we put the aspect-ratio bug back deliberately to confirm the new check failed nine pages, then restored the fix. A check you have never seen fail is not a check

How do enquiries actually reach Jack?

Three ways, and the site pushes hardest on the one a roofer can actually answer while standing on a roof: WhatsApp.

Every form on the site posts to the client’s Gmail inbox through a form service, so no mailbox on the domain was needed. The subject line carries the service or symptom — “Free survey request — Rising damp” — so he can triage from the inbox list without opening anything.

Two hidden fields travel with every submission: which button produced the lead, and which page it came from. That means the client can see whether enquiries come from the Medway page or the flat roofing page, and we can see which calls to action earn their place.

Photographs go via WhatsApp rather than the form. The free tier of the form service does not carry attachments, and rather than let images silently vanish we made the photo step a WhatsApp panel. It is the better route anyway — pictures arrive full size and Jack can reply there and then.

• A multi-step survey form — on the homepage: symptoms, location and history, photos, contact details
• A modal enquiry form — on all 51 calls to action across the site, opening with the relevant symptom already ticked
• A dedicated thank-you page — at /thank-you/, which names the service back to them, sets out the four steps, gives the urgent route, and tells them three free things to do before the survey
• Click-to-call and WhatsApp — pinned to a sticky bar on mobile, always one tap away
• Honest failure — if the form service is unreachable the site shows the phone number rather than a false confirmation

What does the business have now?

A 24-page website on a secure domain, with a page for every service it sells and three of the towns it works in.

Timescale. Designed and built in three days, then live as soon as the client gave the go-ahead.

• One website instead of two, on one domain, with one phone number — the retired 0800 line removed everywhere
• HTTPS with no browser warning, on Cloudflare’s network
• Eleven individual service pages where the old site exposed none on its homepage
• Three location pages — Medway, Dartford and Bexley — each arguing from that area’s actual housing stock rather than a template with the town name swapped
• Ten of the thirteen old URLs resolving to a real page on the same path, and the rest redirected
• Site photography cut from 8.3 MB to 2.6 MB, and mobile first load nearly halved
• 97 for performance, 100 for best practices and 100 for SEO on desktop PageSpeed Insights
• Enquiries landing in the client’s inbox, tagged by service, symptom and source page
• A build and audit pipeline the client owns, so any future change is checked before it goes live

Thinking about a rebuild for your own trade business?

Tell us what your current site is not doing and we will tell you straight whether it needs replacing or just fixing.

See our pricing — whiteskidigital.com/pricing/

Websites for trades — whiteskidigital.com/trades/

Or message us on WhatsApp: 07725 541812

Frequently asked questions