We didn’t build this construction platform — we made it secure, and made search understand it
CanaCore Construction Alliance is a live platform that connects Canadian homeowners and developers with verified contractors. The site was already built and running — but it was quietly exposing form submissions through its own API, it told search engines that every page was the homepage, and it had no tests and no build checks, so nothing could be changed safely. We were brought in to fix the foundation and make the platform legible to search — without touching its design, its brand or the product itself.
- Client
- CanaCore Construction Alliance
- Sector
- Construction & contractor marketplace
- Market
- Canada
- Engagement
- Technical SEO, application-security hardening & content architecture on an existing site
- Live website
- cana-core.com
Services
A site that worked — but could not be trusted, changed or found
Nothing on CanaCore looked broken. It was live, it looked right, and people could use it. Underneath, three separate problems meant it could not be trusted, could not be changed safely, and could not be found.
It could not be trusted. Client form submissions were reachable through the platform’s own API without so much as a login, and a public endpoint that ran up a real bill on every call had no rate limiting and no bot protection at all. The safeguard that was supposed to gate content previews never actually checked anything.
It could not be changed safely. There were no automated tests, no continuous-integration checks, and a type-check that did not pass — so any change, however small, was a gamble. The production build was even pointed at the wrong domain, and the image pipeline was quietly rejecting images because of it.
And it could not be found. The site served no canonical tags at all, and a metadata bug had every page reporting the homepage’s address to search engines. The four most valuable pages — the service hubs — all served one identical, machine-generated title, and around fifteen pages carried machine-generated descriptions that were already live in Google. Content was thin and duplicated, internal linking between the guide and the services was non-existent, a real contact number was a placeholder on twenty-five pages, and one hub was stuck in a redirect loop that made it unreachable.
Fix the foundation first, measure everything, then re-architect the content
We worked in a deliberate order, and entirely inside the site that already existed.
Foundation before polish. First we closed the access-control and rate-limiting gaps and put bot protection in front of the public endpoints, so the platform was safe. Then we made the canonical domain a single, guarded source of truth, gave every page a correct canonical and its own metadata, and fixed the crawl rules and the image pipeline — the plumbing that decides whether search can read a site at all.
Then the safety net. We stood up a continuous-integration pipeline and a test suite where there had been neither, so that from that point on every change could ship with confidence instead of hope.
Only then the content. Distinct, keyword-mapped titles and descriptions across the service pages; a unique FAQ on every one, so no two pages publish the same structured data; headings and positioning rewritten around real search intent; and three new landing pages for the commercial and home-addition demand the site had no answer for.
Throughout, we measured on the live site — every defect reproduced and confirmed before and after the fix, never judged from the code alone. All of it went into the existing CMS behind a full backup and version history. The design, the brand and the product were never touched.
The full engagement, foundation to content
Security & platform integrity
- Closed an access-control gap that let the platform’s own API return client form submissions without authentication — and closed a second instance of the same class in the media API
- Added bot protection, per-IP rate limits, input-length ceilings and request timeouts to the public submission and assistant endpoints, which previously had none
- Fixed a preview-authentication check that never actually verified the user
Technical SEO foundation
- Made the canonical domain a single source of truth, rejecting the hosting-provider origin, with a regression guard so it cannot silently break again
- Added canonical tags across the site — there were none — and fixed per-page Open Graph and Twitter metadata that had every page reporting the homepage
- Rewrote robots.txt with an explicit policy for search and AI crawlers, and stopped it blocking the media path that serves every image and social preview
- Cleaned the sitemap — removed stub and internal-search pages, added missing routes — and added permanent redirects from retired URLs that were returning 404
- Fixed an image pipeline that had been rejecting images because it resolved to the wrong host
Search legibility & metadata
- Replaced the identical machine-generated title on the four service hubs with distinct, keyword-mapped titles, H1s and descriptions
- Replaced machine-generated meta descriptions on around fifteen pages that were already live in search — only where the text was demonstrably auto-generated, never where an editor had written it
- Gave five articles that had no title or description real, page-specific metadata
- Added BreadcrumbList, Service and BlogPosting structured data, and fixed a “Home > Home” breadcrumb on the homepage
Content & architecture
- Keyword-mapped titles and descriptions across roughly thirty service pages
- A unique three-question FAQ on all twenty-five service detail pages, plus bespoke hub-level FAQs, so no two pages publish the same FAQPage markup
- Three new landing pages — commercial construction, commercial renovations and home additions — with real decision-making content: process from estimate to handover, permits and inspections, code compliance, quality control, change orders and what a quote needs
- Cross-linked thirty guide articles and twenty-five service pages in both directions, where there had been no linking at all, and added homepage and hub entry points to the previously unreachable commercial and project-management pages
- Fixed joined-word headings across seven page templates, replaced a placeholder phone number on twenty-five pages, corrected US-specific wording for the Canadian market, and stopped a redirect loop that had made a service hub unreachable
The safety net
- Built a continuous-integration pipeline — type-check, lint, tests and a production build on every change — where none had existed
- Grew the automated test suite from zero to 126 tests, including a regression guard on the canonical domain, and got the type-check passing for the first time
The four decisions that shaped the work
Foundation before polish
You cannot responsibly optimise a site that is exposing data or that you cannot change safely. So the order was fixed: close the security gaps, fix the canonical and crawl foundation, and stand up tests and continuous integration first — and only then touch a word of content. The unglamorous work came first because everything else depended on it.Measure on the live site — and re-verify every finding
Every defect was reproduced on the live site before we fixed it and confirmed on the live site after — never judged from the code alone. That discipline extended to an independent audit that ran alongside the work: we re-tested each of its findings rather than taking them on trust. Half described problems that no longer existed and were dropped; four were real, and we fixed them. We trust measurements, not claims — including our own.Correct the machine, respect the human
The metadata fixes only ever replace a value that is demonstrably machine-generated — a title that reduces to the page’s own slug, a description in the generator’s boilerplate shape. The moment an editor writes real metadata, our layer steps aside and the human wins. It cleaned up hundreds of auto-generated fields without ever fighting the people who maintain the site.Depth where the decision is made
The commercial and home-addition pages carry the highest-value intents on the site, so they got the most content — how a project runs from estimate to handover, how permits and inspections work, how change orders and quotes are handled. Search rewards the page that answers the decision, and so do the people making it. Thin pages get neither, which is why every service page also got its own FAQ rather than a shared one.
How the work was built and shipped
CanaCore runs on a headless CMS and a modern React framework, with pages assembled from CMS content and served through a dynamic route. Our work sat at every layer of that.
On security, we closed the access-control gaps in the built-in content APIs and put bot protection, per-IP rate limits and input and timeout ceilings in front of the public submission and assistant endpoints. On the search foundation, the canonical domain became a single source of truth that rejects the hosting-provider origin, backed by a regression test so it cannot silently regress; canonical tags, per-page social metadata and corrected crawl rules followed.
For the content layer we added a resolver that decides, field by field, whether the stored value or a curated one wins — and the stored value always wins when a human wrote it. A single taxonomy function classifies every page and drives its Service schema, its FAQ set and its article-to-service links, so a page’s category is derived once and used everywhere, and FAQPage markup is only ever built from questions shown on the page.
All of it shipped through a continuous-integration pipeline we introduced — type-check, lint, a suite that grew from zero to 126 tests, and a production build on every change. Content reached production through idempotent scripts run against the live database, each safe to re-run and each reusing existing media, behind a full database backup and the CMS’s own document versioning so any change could be rolled back.
Secure, legible, and safe to change
The platform no longer exposes form data through its API, and every public endpoint is rate-limited and bot-protected. Every page now carries a correct canonical and its own metadata; the four hubs have distinct, keyword-targeted titles; every service page has a unique FAQ and its own structured data; the cannibalising pages are separated and the orphaned ones linked back in; and three new pages answer commercial and home-addition demand the site previously ignored. Where there had been no tests and no build checks, there are now 126 tests and a continuous-integration pipeline — so the site is, at last, safe to change. It is all live on cana-core.com and all pointable-to.
One honest note, and we think it matters. CanaCore has no analytics and no Search Console connected, so the effect of this work on rankings and traffic cannot yet be measured — and we will not put invented numbers on this page to suggest otherwise. Connecting measurement is the first thing we would do next. Everything claimed here was verified on the live site, before and after; the work is the proof, not a graph.
For ICE WIND it is the reference project for a specific kind of engagement: taking a business that already exists, on a platform we did not build, and making it safe, legible and maintainable — without a redesign. That work sits under SEO and AI search optimisation; when the answer really is a rebuild, it sits under website redesign instead.
Have a site that works — but can’t be trusted or found?
An existing business, a site you already like, and problems you can’t see from the front end: data reachable that shouldn’t be, pages search can’t tell apart, no safe way to change any of it. That is the engagement this case is about. We start by telling you exactly what search — and anyone else — can currently see.
Request an auditmanager@icewinddaleconsulting.com
+44 7345 058863