SEO in website development is mostly a sequencing problem. A handful of decisions taken during a build (the URL structure, how content is rendered, what the templates emit, how the old URLs are mapped to the new ones) are cheap to get right before launch and expensive to fix afterwards. Everything else can be improved later. Buyers get into trouble when the site is designed and built first and an SEO is brought in to optimise it afterwards, at which point the recommendations are effectively a rebuild. This guide sets out which decisions genuinely belong in the build phase, how to scope the two roles on one project, and what to check before you sign off a launch.
The decisions that are expensive to reverse
Four things belong in the build. URL structure comes first: a simple, readable, stable path per page, decided once, because changing it later means redirects, lost signals and a period of instability. Google's guidance on URL structure is explicit that simple descriptive URLs are easier to crawl and understand. Rendering is second: if the content only exists after JavaScript executes, you are relying on a rendering pass rather than the initial HTML, and Google's own JavaScript SEO documentation describes that extra step. Third are the templates themselves, which decide whether every page can have its own title, meta description, headings, canonical tag and structured data, or whether the CMS hard-codes them. Fourth is the redirect map on a replatform, page by page from old to new, which is the single most common cause of traffic collapsing at launch.
How to scope the developer and the SEO together
Bring the SEO in at wireframe stage, not at launch. Their job during a build is short and specific: agree the site architecture and URL pattern, define the templates and what each one must be able to output, supply the query map so page titles and headings are aimed at real demand rather than internal vocabulary, and own the redirect spreadsheet. That is perhaps a few days of work spread across the project, and it costs far less than the same person auditing a finished site and recommending changes the developer has already been paid to make once. Write the acceptance criteria into the development contract so they are testable: every page type must support an editable title and description, the primary content must be present in the initial HTML response, and the redirect map must be applied and verified before the DNS change. If the developer resists testable criteria, that is useful information at the point where it is still cheap.
What to check before you sign off a launch
Run the checks yourself, or have someone run them in front of you. Confirm the staging site was blocked from indexing and that the block has been removed on the live site, because a robots directive left in place after launch is a classic and quietly catastrophic error. Confirm every old URL that had traffic resolves to a sensible new one with a permanent redirect, and that nothing chains through three hops. View source on a few key pages and check the main content is there without running scripts. Verify canonical tags point at the page itself rather than the homepage or the staging domain. Check the site is verified in Search Console and that the sitemap is submitted. Then look at page experience on a phone rather than a desktop, because that is where most of your traffic will be and where slow builds actually lose the enquiry.
Buying the build and the SEO from one provider
Combining both in one contract removes the handover problem and the argument about whose fault a regression is, which is genuinely valuable. The risk is that you cannot see the pricing of either half, and that a design-led studio with an SEO line item may be pricing a checklist rather than a discipline. If you buy them together, ask for the two scopes and the two fees separately even under one agreement, ask who the SEO is by name and what they will personally produce, and ask for the query map as a deliverable in its own right before design starts. A site built to a keyword map that you have read and agreed is aimed at something. A site built to a moodboard and optimised afterwards is aimed at nothing, however good it looks.
Questions people ask about seo in website development
Should we do SEO during the build or after launch?
Both, but different work. During the build you settle architecture, URLs, templates, rendering and redirects, because those are costly to change later. After launch you do the continuous work: content, internal linking, improvements based on real query data. Skipping the first set does not save money, it defers a larger bill.
Will a new website hurt our rankings?
It can, and the usual cause is the redirect map rather than the design. If every old URL maps to its closest new equivalent with a permanent redirect and the content survives the move, most sites recover quickly. If URLs change without a map, expect a real and sometimes lasting loss.
Does the platform choice matter for SEO?
Less than people claim, as long as the platform lets you control URLs, per-page metadata, headings, canonical tags and structured data, and serves content that does not depend entirely on client-side rendering. Check those capabilities against the platform before you commit rather than after.
Who should own the redirect map?
One named person, and preferably the SEO rather than the developer, because it is a content mapping exercise more than a technical one. Whoever owns it, the map should be a document you can read, approved before launch, and verified by request after the switch.