SEO & Site Engineering Report

We took the old WordPress site apart and moved its content across. Our tooling read the export, unpacked the page builder layouts, resolved every image and pushed each record into the new CMS, carrying the draft and published states with it. Years of writing, photography and specification detail came over intact, and a migration that quietly loses content loses the rankings that content had earned.

We imported the old pages at the addresses they already had rather than letting the new system invent its own. Address parity is the single biggest lever in a migration, because a page that keeps its address keeps every link and every ranking pointing at it with nothing lost in a hop.

We built the new front end on a framework that renders pages ahead of time instead of assembling them on each request. Pages that already exist as files when a visitor asks for them are the fastest thing a site can serve, and it means the site stays up even when the CMS does not.

We removed the placeholder and test pages our own build was publishing, which came to 18 coming soon pages, a sample product page and a temporary product list. A coming soon page in a search result is worse than no page at all, and each one was a live address a crawler spent effort on.

We wrote the brand's selling points into a single data file, 16 for garden rooms and 16 for gazebos and summer houses, and put one grid of them on the category pages, on every product page and on the why pages. Triple glazing as standard, TRADA certification, marine grade fabrics and installation included are the reasons a buyer picks Crown over something cheaper, and the site had barely mentioned them.

We moved the site's content store onto a new platform behind a switch that let the site read from either one, then turned it on once every collection had crossed. Migrations that rewrite the site at the same time as the data are how sites lose their rankings, and this one changed nothing a visitor or a search engine could see.

We worked through the addresses the old site published and wrote a permanent redirect from each one to its replacement, covering blog posts, product pages, category pages and short aliases. Every old address that still carries a link now passes that value to the page that replaced it instead of landing on nothing.

We kept the redirect list inside the hosting platform's rule limit. Cloudflare counts every rule that follows a wildcard against a cap of 100, so we moved the wildcards to the end of the file. Rules past that cap are ignored without warning, so hundreds of redirects would have looked correct in the file and done nothing on the live site.

We built a checker that walks the whole rule list, requests each address and records where it actually lands. A file this size cannot be checked by eye, so the checker is what turns the redirect map from an assumption into a result we can reproduce after any change.

We cleared the backlog of missing addresses Search Console had been reporting, writing a rule for every one with a sensible destination. A missing page tells Google to drop the address and tells the visitor they made a mistake, so this was the largest single recovery item in the remediation work.

We settled the site on one address format for every page. It had been answering on both the trailing slash form and the form without it, which meant two addresses for every page splitting the signals between them, and we turned on page compression in the same change.

We retired the dead offers section the old site left behind and pointed every old offer address permanently at the wooden gazebos range. The links those pages earned over the years now reach a page that sells, and that redirect answered correctly when we checked it on 07 August 2026.

We published an XML sitemap generated from the site's real routes at build time, left the internal preview and listing paths out of it, and published a robots file pointing at it. A sitemap is how a search engine learns about pages nothing links to yet, so publishing one at launch got the new addresses discovered in days rather than whenever a crawler wandered in.

We marked up the FAQ blocks on the homepage and on the use case pages, built from the questions already shown there. Marked up answers can appear directly in a search result and feed the answers assistants give, and the questions had already been written.

We added product codes and categories to the product markup, which had carried the name and the price and nothing else. A fuller record is what qualifies a page for the richer product result, and it helps shopping and AI surfaces match the page to the thing someone actually asked about.

We put the live Trustpilot rating into the homepage markup, reading the current score and review count from the site settings rather than fixed numbers that go stale, and extended the profile list to name the company's LinkedIn and X profiles alongside Facebook, Instagram and YouTube. The rating block is what puts stars on a search result, and the profile list is how Google learns that the company on this site, the company on LinkedIn and the company on X are the same company.

We set an explicit policy for AI crawlers, naming the ones that may read the site and the ones that may not. The assistants that send referral traffic can read it and the bulk scrapers that send nothing back cannot. A growing share of buying research now happens inside an assistant rather than on a results page.

We published a plain text map of the site at its root listing the key pages, the product categories, the use case pages and the contact details. Assistants read that file instead of guessing the shape of the site from its navigation, which gives them a clean route to the pages Crown wants quoted.

We carried the old site's search settings across with the articles. Each WordPress article held its own search title, description and target term, and we brought all three into the new CMS rather than letting the import drop them. Those settings were years of editorial decisions about how each article should appear, and losing them would have meant Google rewriting every listing from scratch on the day of the migration.

We wrote the page descriptions. Several main pages including the homepage had gone live with none, so Google composed its own from whatever text it found first. The descriptions we wrote name the products, the materials and the show sites, which means the listing says what Crown sells rather than whatever fragment a crawler picked up.

We rebuilt the search and social metadata on every blog page so titles, descriptions and share images come from fields the editors already fill in, and added published and updated dates, section and tag information, image dimensions and alt text, next and previous links across paginated listings and visible breadcrumbs. Twelve separate faults had been stopping blog pages presenting properly in search and on social.

We put the blog archive back into search. The listing layout had been marking every page after the first as not for indexing, so page two onward of every category had dropped out of Google and older posts sat behind a wall nothing crawled through. Removing it opened up years of writing that had gone invisible.

We corrected the roof options described on gazebos and summer houses. The selling points offered a cedar roof only, when gazebos take cedar or thatch and summer houses take cedar. The roof is one of the first decisions a gazebo buyer makes, and describing half the choice sent people away to ask a competitor whether thatch was possible.

We rebuilt the blog as one system with a single article type, one listing page and one article template, and moved the legacy files out. One system means one address per article, one place to publish and one template to improve, where splitting the archive across two sections had been dividing the ranking value between them.

We gave every article a real publication date. Articles had been ordered by the date their record was created, which for everything brought over was the day of the migration, so every article on the site looked as though it had been written on the same day. Search engines read that date, and so does a reader deciding whether an answer is still current.

We put a named author with a photograph and a biography on every article, and added a related articles block underneath. Google reads authorship as one signal of whether advice comes from someone who knows the subject, and so does a reader considering a building that costs as much as a car.

We audited all 71 FAQ answers against the current selling points, the current pricing and the live addresses, found 16 problems across 14 answers and wrote replacement copy for each. One answer told visitors that garden rooms come with double glazing when every garden room ships with triple, and FAQ answers travel further than ordinary page copy because search results and AI answers quote them.

We wrote the comparison pages that answer why Crown costs more, covering ten criteria that define a premium garden room with a six brand roster, like for like pricing and nine detailed tables, plus a second page comparing the gazebo range against a named competitor. The price question is the one that decides the sale, and it was being answered in a phone call or not at all.

We corrected a claim in the comparison table about foundations. The row overstated what Crown offers as standard, so we changed it to say the option is available subject to a ground screw test. A comparison page only works while every row survives being checked, and one overstated claim on a page built to prove Crown is the honest option would have undone the whole argument.

We stood up the content management system the site runs on, added its query interface, wrote the library that lets the site read from it and packaged the whole thing so it deploys the same way every time. This is the foundation everything else sits on, and every change the team makes without a developer goes through it.

We automated the release so publishing does not need a developer, wiring the CMS to trigger a rebuild and redeploy on its own and adding the diagnostics needed to see why a deploy failed when one did. Publishing used to end with someone asking a developer to release it.

We fixed a data fault that was silently cutting lists off at ten items. The CMS returns ten entries from a nested list unless the query asks for more, and ours did not, so galleries, features and related items across the site were quietly truncated. This was invisible from the admin panel, where an editor could add a twelfth gallery image, watch it save and never see it appear.

We found and removed 67 duplicate pages we had introduced. A catch all route in our own build was publishing 67 legacy records at their own addresses alongside the real pages, so we removed the route and left the data untouched. We introduced it and we caught it. Two addresses describing the same product split its ranking signals so neither wins, and clearing them gave every page a single address again.

We cut the number of CMS calls each build makes. The testimonials block ran its own query on roughly 240 pages, so one build made the same call 240 times, and we moved those queries into shared helpers that hold the result for the length of the build. That turned publishing from something the team had to ration into something routine, and nothing about the rendered pages changed.

We made the video hero take its slide copy from the video edit. The editor already sets markers while cutting the film, so we read that marker file at build time and turn each marker into a slide, with the marker name as the heading and its link as the button. Nobody retypes headings into a CMS and nobody waits on a developer to change them, which turns the homepage hero from a yearly project into something the marketing calendar can use each season.

We built a form system that records where every enquiry came from, storing each one with the campaign parameters from the visit that produced it. Marketing can now see which campaign, which channel and which page produced a lead instead of guessing, and that is the number that decides where the next pound of advertising goes.

We added a Book a Visit form to every showroom page and fixed a fault that was clearing what the visitor had typed as the page finished loading. A showroom visit is where this product sells, and putting the booking on the page for that specific showroom removes the step where the visitor has to find the contact page and explain which one they meant.

We set up an alert for when a lead fails to send, so the team gets a message with the details rather than the enquiry disappearing. Silent lead loss is the most expensive failure a site can have, because nobody knows to look for it.

We repaired the showroom list that had been empty on the booking form. The form fetched its list without the credential the CMS requires, so the request came back with nothing and the dropdown rendered empty on the live site. Anyone trying to book a visit reached a form with nothing to choose, on the highest intent action the site has.

We brought every finance figure on the site under one module. It holds the plan terms and works out the monthly figures, so every payment shown on the site comes from one place. We built the representative example the regulator requires, put it behind a disclosure on product pages with the headline rate always visible above it, and put an open version on every listing page. Where a product had no figures we removed the monthly claim rather than showing an estimate. The lender's compliance audit had failed the site, and the finance route would have stayed closed until it passed.

We made a finance policy change a single edit rather than a hunt. The plan quotes two separate figures and the choice between them moves every monthly payment on the site, so we raised it and the client instructed us which one to use. Every revision after that landed as one change to one constant in one module. Before this work the same calculation sat inside six separate components, so each revision would have meant finding all six and hoping we had.

We made the homepage show its main image sooner. We held back everything the first screen does not need, told the browser to fetch the hero image first, converted the brand fonts to the modern compressed format and served them from our own domain instead of a font service. The largest image on the homepage is what Google times when it measures loading, and the same fonts serve every other page on the site.

We converted the site's photography to a modern image format. We wrote a tool that finds every heavy image, converts it, rewrites the references in the code and reports the bytes saved, then ran it across the whole library while keeping the originals so we could roll back. Photography is the heaviest thing on the page for a business that sells on how its buildings look, and lighter files mean the pictures arrive sooner for someone standing in a garden on a phone.

We loaded the garden room 3D configurator only when a visitor scrolls to it. The tool sits well down the page, so loading its heavy embed up front would have slowed the part everyone sees. Holding it back gives the buyer the tool without charging every visitor for it.

We tuned the homepage video so it does not cost the page its speed, capping the streaming quality, limiting how far ahead the player buffers and holding the video back until the page has finished the work that matters first. A video hero is the usual way a site loses its loading score.

We served product and blog images through the hosting network's edge cache. Images had been pulled from the media store on every page view, so we routed them through the site's own address and added a header that lets us confirm the cache is working. Visitors now get images from a server near them, and the media store went from being hit once per visitor to roughly once per image, which pulled a running cost back under its allowance.

We built automated tests that submit the site's forms before every release, filling in and sending the contact form, the brochure request and the showroom visit booking and checking that the campaign tracking travelled with them. A form that quietly stops working costs enquiries for weeks before anyone notices.

We set up screenshot testing that flags any unintended visual change, capturing every page in several browsers, comparing each against the approved version and collecting the differences in a gallery we review. On a site this size a change to one shared component can break a page nobody thought to check, and the screenshots surface that in minutes instead of after a customer reports it.

We fixed a gallery that was only ever showing its first ten images, because the query behind it never asked for more. Buyers were seeing a fraction of the photography that exists, and for a business that sells on how its buildings look, hidden images are lost enquiries.

We caught and reversed files our own image tool had removed. The tool we wrote to shrink the image library deleted archive files it should have left alone, and a local setting was hiding some of them from review. We found the fault inside our own change on the same day, restored every file and added tests covering the cases that tripped it up. Nothing reached a customer.

We made the mobile menu impossible to break. An error anywhere else on the page could stop the menu script running, which left the hamburger button dead, so we isolated the menu to run on its own regardless of what else fails. On a phone the hamburger is the only route to anything, and a menu that silently refuses to open ends the visit there.

We made the build refuse to publish a site with missing content. If a content collection came back empty the build carried on and published pages with nothing in them, so we made an empty collection stop the build instead. A silent empty build is the worst kind of failure, because the site stays up and looks broken.