Web Design for GBR Hoarding — Scaffold Shrink Wrap Contractor, Greater London

What was actually wrong before we started?

There was nothing online except an Instagram account with 25 posts. GBR Hoarding is a shrink wrap specialist run by its founder, George Bejenaru, from Plumstead in south-east London. It had built up years of work on central London facades through word of mouth from scaffolders and main contractors, but anyone searching for scaffold shrink wrap in London would not find it. The trade also sells two things alongside the wrap, Monoflex sheeting and site hoarding, and nobody who had not already worked with George knew that.

The client had no logo file, no brand guidelines, no photography beyond phone shots on Instagram, no domain content, and no email on the domain. The reference the client sent for the look was a competitor’s website. The brief was to build a modern site that sold the business hard, educated buyers on when shrink wrap is the right product, won local search across six named areas, and pushed every visitor towards WhatsApp.

Why we built it as static HTML on Cloudflare rather than WordPress?

Because the site had to be fast, cheap to run and impossible to break, and the client will never edit it himself. A one-man contractor does not want a CMS to update, plugins to patch or a hosting bill that grows. Every page is a flat HTML file generated from a single build script, so the header, footer, mega menu, enquiry pop-up and schema are identical on all 25 pages and a change in one place updates everything. The Cloudflare Worker serves the files as static assets with extensionless URLs, a real 404 page and no server to maintain.

• One shared stylesheet of about 33KB and one deferred script. No frameworks, no jQuery, no page builder.
• A build script (Python) that stamps every page with the same shell, rewrites links to clean URLs, adds image dimensions and writes the sitemap.
• Every page renders fully with JavaScript switched off. Menus and the pop-up need it; the content does not.
• Photos converted to WebP at two sizes with srcset; the hero image on each page is preloaded. Home page first load is about 510KB, service pages about 400KB, legal pages about 180KB.

How did we get a logo out of a photo of a sticker?

We cut it out of the raster and knocked the background to transparency. The client’s only brand asset was a round navy badge with a heavy, wide GBR wordmark, a vertical bar and PROFESSIONAL SHRINKWRAP alongside it, plus the strapline Protecting What Matters. There was no vector file and the client had no way to get one quickly. Our first attempt rebuilt the lock-up in type, which the client rightly said did not look like his logo. So we took the clearest version of the badge he could supply, isolated the centre lock-up and the strapline, removed the navy pixel by pixel to a transparent PNG, and used the same method to lift the small GBR roundel from the top of the badge for the favicon, Apple touch icon and a footer mark.

It is still raster, so it will not scale to a banner. The client knows to send a vector if one ever surfaces; it is a one-file swap.

• Header: lock-up on transparent background, 16KB after palette quantisation.
• Footer: lock-up with strapline, 18KB.
• Favicon set: 32px, 180px Apple touch icon, 512px and .ico, all built from the roundel on a navy disc.
• Display type chosen to sit with the badge: Krona One for headings, Michroma for the wordmark fallback, Inter Tight for body.

How did we stop the site looking like the competitor?

By taking the one good idea from the reference and rejecting everything else. The client had sent a screenshot of a rival shrink wrap company’s site for the phone-based lead magnet: a mocked-up WhatsApp conversation next to three steps for sending a photo. That is a strong pattern for this trade, so we kept the idea. Our first draft, though, pulled an orange accent from a panel in the client’s own badge, and combined with a dark background and numbered steps it drifted too close to the competitor’s purple-and-orange look. The client caught it immediately and said so. We removed every orange element, deepened the background to a true navy, rebuilt the phone section with different copy, layout and chat, and dropped the numbered markers. The palette is now navy, mid blue and white only.

What pages did we build and what is on them?

Twenty-five pages, each written as a sales page rather than a brochure page. Every service and location page follows the same spine: hero with two calls to action, trust strip, a long article with a sticky sidebar, the WhatsApp phone section, a page-specific FAQ, and a closing call-to-action band. All copy was written by us from the client’s brief and a phone call; nothing was pasted from elsewhere.

• Home. Hero, three pillars from the badge, three service blocks, a shrink wrap versus Monoflex comparison table, a 12-image gallery, the phone section, a founder block, six area cards, FAQ and CTA.
• Three service pages. Scaffold shrink wrap (about 1,900 words), Monoflex sheeting (about 1,500) and site hoarding (about 1,400). Each has anchored sub-service sections the mega menu deep-links to, a how-the-job-runs process, a who-it’s-for grid, a gallery and eight FAQs. No locations on these pages; that is what the location pages are for.
• Training. The client sells a one-day on-site shrink wrap course. We wrote it up as a full sales page with Course schema and put an upsell band low on each service page.
• About, contact, projects, areas hub. Contact has an inline enquiry form, WhatsApp, phone, email, Instagram, LinkedIn and a map. Projects is a designed gallery of 15 images.
• FAQs. 41 questions in five groups with a live search box that filters as you type.
• Blog. Index with category filter and a right sidebar, plus five articles of 1,150 to 1,320 words each, titled the way people search.
• Legal. Privacy, cookie and terms pages written for this trade: scaffold sign-off before wrapping, wind loading is the designer’s responsibility, highway licences are the client’s, weather delays, patch call-outs.

How did we structure the local SEO for Greater London?

Six standalone location pages, one for each area the client asked to win, kept separate from the service pages so each page targets one intent. GBR is based in Plumstead, on the Woolwich and Charlton side of the Royal Borough of Greenwich, and works across all of London, so the location pages cover the areas where the client already has work or wants it: Kensington & Chelsea, Greenwich, Silvertown, the Royal Docks, Barkingside and Brent Cross.

We make no ranking promises. The site is built to be crawled and understood correctly, the location pages are written for real local intent, and the client has been given a Search Console and Google Business Profile checklist for launch. What Google does with that is not something we or anyone else can guarantee.

• Location pages: /shrink-wrap-kensington-chelsea, /shrink-wrap-greenwich, /shrink-wrap-silvertown, /shrink-wrap-royal-docks, /shrink-wrap-barkingside, /shrink-wrap-brent-cross, plus an /areas hub.
• Each has an H1 on the primary keyword, a postcode strip, local copy on the building stock, borough licence and conservation rules, travel time from Plumstead, a neighbourhood grid of 10 to 12 named places, a local WhatsApp chat on the phone mock-up and a local FAQ. Postcodes are in the title tag.
• Service pages have keyword slugs with no location: /scaffold-shrink-wrap, /monoflex-scaffold-sheeting, /site-hoarding.
• Unique title (28 to 61 characters) and meta description (86 to 160) on every page. One H1 per page and a clean H2/H3 tree; the footer column headings were originally H5s and broke the heading order on every page, which the audit caught and we replaced with styled divs.
• JSON-LD on every page: LocalBusiness site-wide, Service, FAQPage and BreadcrumbList on service and location pages, Course on training, BlogPosting on articles, AboutPage, ContactPage, CollectionPage and Blog.
• Canonicals, Open Graph and Twitter tags, robots meta, sitemap.xml with 25 URLs, robots.txt, noindex 404.
• Width and height on every image so layout shift measures zero, lazy loading below the fold, deferred script.

How do enquiries actually reach the client?

By WhatsApp, first and by design. Shrink wrap is priced from photographs: a shot of the whole scaffold, one of the street side, the postcode and the number of storeys is enough for George to give a firm price the same working day. So the primary button on every page opens WhatsApp with a pre-filled message specific to that page, a floating WhatsApp button follows the visitor, and a mocked-up chat on each service and location page shows exactly what to send.

For buyers who would rather not use WhatsApp there is an Enquire now pop-up on every page and an inline form on the contact page, both posting through Web3Forms to enquiries@gbrhoarding.co.uk with no server code. Web3Forms does not accept file uploads, so the forms say so plainly and point photos to WhatsApp or email rather than leaving people hunting for an attach button. The service dropdown includes training so course enquiries are tagged. Phone and email are on every page.

What does the business have now?

Five working days from brief to go-live-ready, with the first design on the client’s screen the same day as the brief.

• A 25-page site that loads in well under a second on a local server and renders without JavaScript.
• A brand lock-up, favicon and footer mark rebuilt from a photo of a sticker.
• Three long-form service pages, a training sales page, six local landing pages and a five-article blog, all written from scratch.
• Every enquiry route wired: WhatsApp with page-specific messages, pop-up form, contact form, phone, email.
• Full structured data, sitemap, robots, 404 and a go-live checklist covering Search Console, Google Business Profile and the two company details still to be added to the legal pages.
• Nothing to maintain: no CMS, no plugins, no database, hosting that costs almost nothing.

What nearly went wrong?

Two things, both on the live server rather than in our previews. The scroll-reveal animation used an intersection threshold of 15%, which means an element has to be 15% visible before it fades in. The article column on a service page is several thousand pixels tall, so 15% of it never fits in a viewport, and on the live site the main content of every service page stayed invisible while the short sidebar showed. The client spotted it; we replaced the observer with a plain top-edge check and a timed fallback, then audited all pages at desktop and mobile widths by scrolling them naturally rather than forcing the reveal on, which is how we had missed it. Later, adding width and height attributes to every image for the layout-shift score let the pixel height override the CSS crop, and every gallery card stretched to its full portrait height. One global rule fixed it and an automated pass measured every image on every page to confirm.

Want a site that sells your trade the way this one does?

See our pricing (/pricing/), web design in Plumstead (/web-design-plumstead/) and web design for scaffolders and shrink wrap contractors (/web-design-for-scaffolders/). Or WhatsApp Shaun on 07725 541812 and we will show you your homepage before you commit.

Frequently asked questions