Three scenarios where SEO is needed before launch
Formally this is one service, but the tasks inside it differ. Which scenario you are in determines both the scope of work and what counts as a result.
| Scenario |
Main objective |
Main risk of skipping it |
| New website |
Build structure around demand and meet technical requirements from the start |
The site launches with no pages covering part of the demand; a rebuild follows |
| Redesign of an existing site |
Keep what already works and fix what was holding it back |
Pages and URLs that were bringing traffic disappear |
| Migration to another CMS or domain |
Move everything without breaks: URLs, content, structured data, settings |
Rankings lost to redirects that were never configured |
The difference between the first scenario and the other two is fundamental. A new site has nothing to lose — the job is to build. A redesign or a migration involves results already earned, and the job is to avoid destroying them along the way.
Why this costs less than fixing it after launch
Every agency claims the early approach saves money, so it is worth showing exactly where the saving comes from.
Before launch, a decision costs a discussion and a line in the brief. After launch, the same decision means:
- a new technical brief and a second round of developer time;
- migrating existing content into the new structure;
- a mapping document of old to new URLs, plus redirect configuration;
- updating internal links across the entire site;
- a period while the search engine reindexes the changes — during which some rankings dip.
The last item has no invoice attached to it, but for a trading business it is usually the most expensive one.
What the work covers
Keyword research and site structure
Collecting queries in your market, grouping them by intent, and comparing the result against how competitors ranking in search have built their sites. The output is a list of pages the site needs, each tied to a group of queries. This becomes the basis of the navigation, not a separate document filed under "SEO".
URL structure
Rules for how addresses are formed for every page type: categories, subcategories, product pages, filters, pagination. This is also where it is decided which filter pages should exist as separate URLs at all and which should be kept out of the index. On an online store, this is one of the most expensive items to get wrong.
A technical brief for the developers
The document the team builds from: requirements for templates, for metadata generation, for error handling, for redirects, for structured data. It is written for a specific platform — what is trivial on one CMS needs a different solution on another.
Metadata templates
Rules for generating Title and Description automatically across templated pages, so that a thousand product pages do not go live with empty or identical metadata. Key pages get metadata written by hand.
Speed and Core Web Vitals
Performance requirements are built into the design and the front-end: image weight and formats, loading order, deferred scripts, layout stability while the page loads. Handled after launch, part of this has to be redone together with the design.
Structured data
Markup for the organisation, products, services, breadcrumbs and reviews, depending on the type of site. Built into the templates rather than added page by page later.
Indexing and technical configuration
robots.txt, sitemap, canonical tags, duplicate handling, language versions and the links between them. Separately: keeping the staging environment out of the index — a common and very unwelcome situation is an unreleased version of a site turning up in search results.
Analytics from day one
Tracking, goals and events are configured before launch rather than a month after it. Otherwise the first month of a site’s life — the most informative one for understanding behaviour — simply goes unmeasured.
Pre-launch verification
Checking what was built against what was specified: crawling the staging version, verifying URLs, metadata, structured data, speed and redirects. An error found here costs the fix; the same error found a month after launch costs the fix plus the lost time.
Website redesign and migration: how not to lose traffic
This is a distinct block of work, and its logic differs from working on a new site.
Recording the current state
Before anything changes, a full picture is captured: every existing URL, its traffic and rankings, the pages holding external links, the current metadata. Without that baseline there is no way to verify that everything was carried over — and no way to identify what broke if traffic drops.
What is kept and what is changed
Pages that bring traffic and hold backlinks are kept at the same addresses wherever possible. Renaming a working URL for the sake of tidiness is the most expensive decision available. What changes is what was not working: duplicates, empty pages, sections built for demand that does not exist.
The redirect map
Every old URL is mapped to a new one. Pages with no direct equivalent point to the closest relevant section rather than the homepage — bulk redirects to the homepage are treated by search engines as an error.
Monitoring after launch
The first weeks after publication matter most. Crawl errors, reindexing speed and the rankings of key pages are all monitored. Some problems only surface on a live site, and they need a response immediately, not in the monthly report.
Ways to work together
The scope depends on the stage the project is at and who is building it.
| Format |
When it fits |
What you receive |
| Technical brief before the build |
A concept or wireframes exist; development has not started |
Site structure, URL logic and implementation requirements — a document the team builds from |
| Development supervision |
The project is underway and needs oversight as it goes |
Input into task definition, answers to the team’s questions, stage-by-stage verification |
| Pre-launch review |
The site is nearly finished and needs an outside check before publication |
A prioritised list of errors and what must be fixed before going live |
| Redesign or migration support |
A live site is changing design, CMS or domain |
A baseline of the current state, a redirect map, a launch checklist and monitoring in the first weeks |
Which format you need becomes clear after a short conversation about the project: size of the site, platform, stage, and who is doing the development. Pricing is set out on our pricing page and depends on the scope of the project.
How we work with development teams
It makes no difference who builds the site — us, your in-house team or an external contractor. Only the format of the collaboration changes.
When we handle development, the SEO specialist works inside the project and tasks are set directly. When the developer is external, we write requirements so they can be implemented without further explanation: with page types, examples and the expected outcome, rather than as general recommendations.
Working within the constraints of the platform matters just as much. Some requirements are implemented differently on a given CMS than the textbook suggests, and some cannot be implemented at all. We have worked with WordPress, Shopify, Horoshop, OpenCart and a number of other platforms, so requirements are written against what can realistically be delivered.
What makes our approach different
Requirements are written for your platform, not in the abstract. A brief that ignores what the CMS can do comes back from the developer with questions, and the stage starts again.
We verify the implementation ourselves. Handing over requirements and finding out how they went after launch is the most common arrangement and the worst one. Verification happens on staging, before publication.
We do not quote projected figures before an audit. How much traffic a site will produce after launch depends on the market, the competition and the volume of work that follows. Targets are agreed once the keyword research is done and the real shape of demand is visible.
We say when the work is not needed. If the site is small, demand in the market is minimal and the budget is tight, separate development supervision may be unnecessary — and we will say so directly.
How to start
You can come to us with a finished brief or with nothing more than an idea for the site.
- A short introductory call. We establish the objective, the stage of the project, the platform, the size of the site and who is doing the development. We do not review the site at this stage — that is the work itself.
- Agreeing format and scope. The format from the table above that matches your situation is selected, and the scope of work, stage deadlines and cost are then fixed.
- The work. Keyword research, structure, technical brief, implementation supervision — depending on the format chosen.
- Pre-launch verification. What was built is checked against the requirements, and you get a list of what must be fixed before publication.
If the site is already live and the question is its current condition rather than its development, an SEO audit is the more logical starting point. If it is launched and needs sustained work, that is SEO promotion or a one-off website optimisation.
Projects where development and search promotion ran together are collected in our development case studies and SEO case studies.
Frequently asked questions
Can SEO be brought in once development has already started?
Yes, and it happens often. Earlier is better, but even a pre-launch review catches most technical problems. There is only one genuinely difficult case: the site is already published and it turns out the structure does not match demand.
How long does it take?
It depends on the format and the size of the site. Keyword research and structure for a small site take a few days; for a large store, weeks. Development supervision lasts as long as the development does. Deadlines are fixed once the scope is clear.
Do we have to build the site with you?
No. We work with your in-house team and with external contractors. In that case our part is the requirements and the verification of what was built.
What if the developer says a requirement cannot be implemented?
We find out where the constraint actually is. Some requirements have alternative solutions on the same platform; some genuinely cannot be done, and then a compromise is found. This is a normal part of the process, which is why requirements are written against a specific CMS in the first place.
Can rankings survive a complete redesign?
If URLs and content are preserved and the technical side does not get worse, then usually yes. The risk lies in changing structure, addresses and copy at the same time as the design. That is why the current state is recorded before a redesign and changes are sequenced by priority.
Is a separate audit needed before a redesign?
What a redesign needs is a baseline: which pages bring traffic, where the backlinks are, what is already working. That is narrower than a full audit and is included in redesign support. A full audit is for a site that is staying as it is, where the question is why it is not performing.
When will the first results appear?
A new site starts being indexed within a few weeks of launch, but rankings for competitive queries accumulate over months — a normal timeline for any new site. For a redesign or a migration the result is measured differently: holding current performance rather than growing it. Targets and metrics are agreed after the keyword research, when the real picture is visible.
