When to Bring in an SEO Consultant During a Website Rebuild

This is a problem I am regularly having to deal with. The Figma files are signed off. The designer has moved into build mode, stitching pages together in the CMS one template at a time. Everyone is happy when the "creative bit" is done, it looks great. But this the moment most businesses either call an SEO consultant too late or never bother at all, because everyone is an AI generated SEO genius these days.

I've watched this pattern play out for over two decades where the SEO person is locked out until the costly mistakes are made. Some things never change. Designs change, platforms change, but this mistake never seems to.

The stage everyone treats as optional

A lot of teams think of SEO as important but something you add into the mix once the site looks finished. But that’s where the problem starts. URL structure, schema markup, heading hierarchy, internal linking and image handling  should all get decided now, while pages are being coded, not afterwards while a client waits for the rankings to recover.

It’s a very simple question: would you rather brief your developer once, correctly, or pay them twice for the same page?

Why waiting until launch costs more

Fixing SEO after a site goes or close to going live isn't a quick tidy up. It means undoing decisions that are already built into working code, and every one of these takes time and costs money.

1. Developers end up recoding templates that were already signed off, so the client pays for the same page twice.
2. Redirects mapped after the fact, rather than planned against the old site's existing rankings, risk losing authority that took years to earn.
3. Content written without proper research into topics, entities and search intent is often rewritten once someone finally checks whether it answers the questions people are asking.
4. Schema markup bolted on retroactively means touching every template again, rather than adding a single line once.
5. Search engines and AI crawlers index whatever goes live first. If that version is wrong, duplicate content and confused signals can take months to unwind, even after the fix goes in.

None of this is really an SEO problem at that point. It's a budget problem, created by sequencing the work in the wrong order.

The window that actually matters should be right now

The ideal moment for a consultant to step in is exactly where this project sits today: the design has been agreed, and the pages are under construction. I tried to explain this to someone this week after I was told that my gig was going to start after the site was built. It was one of those awkward moments when I was trying to explain why the following should be happening alongside the build, not after it. And here’s why.

1. URL structure and site architecture should be agreed before a single page goes live, so nothing needs restructuring later.
2. Schema for organisations, products, events, articles and FAQs should be built directly into templates, rather than added page by page after launch.
3. Heading hierarchy and internal linking should be mapped against the site's core topics, so authority flows to the pages that need it.
4. A redirect strategy should be planned against the existing site's rankings, so it protects traffic instead of guessing at it once the old URLs disappear.
5. Content structured for how large language models actually parse a page: clear entities, direct answers, and consistent terminology across every page that touches the same topic.

That last point matters more each year. Being found in a search results page and being cited inside an AI Overview or a chatbot answer are two different skills, and both depend on decisions made at template level before launch, not on anything a writer can fix in an existing paragraph afterwards.

Where Yoast helps, and where it stops helping

Yoast is a genuinely useful plugin, and there's no reason to knock what it does well. It pushes writers towards better readability, gives a sensible title tag template, prompts for a meta description, and generates a basic sitemap without any hassle. For a single blog post on an already established site, it earns its keep.

A rebuild asks questions Yoast was never built to answer.

1. Yoast works at the page level once a page exists. It has no opinion on the architecture of a site before those pages are even built.
2. Its schema output is generic and rarely matches what a rebuild needs for product pages, event pages, or layered campaign content that requires several schema types working together.
3. It cannot plan redirects across a full migration or protect rankings when URLs, domains or entire page structures change.
4. It has no visibility into how AI systems parse, summarise or cite a page, which is now a measurable channel in its own rather than a future concern.
5. It flags duplicate content within a single post but won't diagnose why an entire template is generating the same schema keywords across dozens of posts. I recently audited a client site where every blog post carried an identical keywords string buried in its structured data, invisible to the writer, and working against the site in every AI crawl until someone went looking for it.

That last kind of fault sits at template level. No plugin checks a template. A person does.

So, do you still need an SEO expert?

The honest answer is yes, but not for the reasons many people assume. Nobody needs a consultant to fill in a meta description field. Yoast does that perfectly well on its own.

What a plugin can't do is stand back and look at the site as a whole. It has no view of how one template's schema should relate to another, how authority should flow between category pages and product pages, or how one flawed template choice gets copied silently across every page built from it. That's a structural view, and structure is exactly where the expensive mistakes hide. A consultant's job is to catch those before they're built, rather than tidying them up afterwards.

This is also the cheapest point in the entire project to have that person involved. Once templates are coded and content is loaded, every fix becomes a rebuild of something that already exists. Right now, while pages are still being built, the same fix is just a series of decisions of what’s do-able.

So, if the build is already underway, ask the designer one question before the next sprint starts: has anyone confirmed how each page's schema and URL structure will work before it goes live? If the answer is no, which is normally the case, that's the conversation worth having this week, not the one you're forced into after launch.

Hopefully someone will read this, take heed and save themselves a fortune while the site is being built out. Honestly, it does happen from time to time.