A migration off WordPress or old hosting without losing positions and without a day of downtime.
A site that has traffic and cannot afford to lose it.
The new version first stands on a temporary address with indexing blocked. Content, media and the old addresses move together, old paths get 301s, and the domain is switched only after you accept the result. The old version stays as a way back.
The scope also covers what usually falls out of a migration: a performance audit after the move and a full set of structured data, because without them a new site loses what the old one had earned.
Moving an existing site to a new stack and a new server without losing search positions and without a day of downtime.
The new site first stands on a temporary address with indexing blocked. Content moves together with the old addresses, old paths get 301 redirects, and the domain is switched only once the new version works.
The old one stays as a way back until nobody needs it. Four sites went through this from their previous hosting, three of them off WordPress.
What you getMapping old structures onto new content types, rewriting redirect rules, migrating entries.
Deciding which addresses carry value, handling the edges (trailing slashes, numeric URLs, duplicates) and checking after cutover that nothing dropped out of the index.
Metadata, canonicals, sitemap, internal linking — and the decision about what belongs in the index at all.
The most common mistake on AI-generated sites: everything is indexable. Thousands of filter URLs, the crawl budget burned, and the site still does not grow. Here filtered views get `noindex, follow` and a canonical to the clean path.
Internal linking is a feature, not editorial goodwill: "more in this category", "previous and next", "similar by tags" and category and tag hub pages are generated from the data.
What you getDraft meta descriptions, spotting missing metadata, generating OG images.
Deciding what belongs in the index, and making sure internal links come from the data rather than from an editor’s memory.
Describing content in the format search engines and AI models read. Here it is a requirement, not an add-on.
One graph per page. `Organization` and `WebSite` with a search action sit once in the layout, and page nodes link to them by `@id`. On top of that: breadcrumbs and the narrowest entity type for the page — `Store`, `BlogPosting`, `Event`, `Product` with an offer, `FAQPage`, `HowTo`, `Person`, `Book`, `VideoObject`.
The hard rule: structured data must match what is visible on the page. A language model will happily add a 4.9 rating from 87 reviews that do not exist. That is a straight path to a penalty, not to stars in the results.
What you getA first pass of the graph from the content model, and spotting gaps.
Matching the type to the content and making sure the graph claims nothing the page does not show.
Speed work measured with a tool, with a record of what helped and what did not.
Measured with the same engine as PageSpeed, locally, with the flags that cut out the browser artefact on a Mac — without them first paint lands about 1.5 s later and the whole analysis is fiction. A median of several runs, not one result, because a single run sits inside the tool’s own spread.
A result from a real project: mobile 81 → median 91 (spread 87–92), page weight 793 kB → 415 kB, fonts 166 kB → 105 kB and 10 files → 5, accessibility 96 → 100 on mobile and 92 → 100 on desktop.
What you getA first optimisation pass and spotting the obvious losses.
Measurement that tells the truth, and rejecting changes that only look good on paper. One such "57 kB saving" produced CLS 0.22 and minus 11 points — reverted.
A site whose content you change yourself: blog, catalog, events, products. Strapi 5 for the panel, Next.js for the front.
Two separate repositories joined by an OpenAPI contract. The API publishes a static contract file, the front generates a client from it and keeps that client in its own repository.
It sounds like a detail and it decides how calm your Sundays are: the build needs no access to the API, so it is deterministic, and every change to the content model shows up as a change in the front-end code — not as a production outage.
What you getThe content model from a description of the domain, list and detail components, SEO fields, sample data migration.
Model boundaries (what is a relation and what is a component), permissions, query performance, avoiding n+1, caching and its invalidation.
That is what the address map and the 301s are for. In one project there were about forty rules: trailing slashes, changed slugs and old numeric URLs. All of them written down in the repository.
It stays as a way back until the new one is proven. Only then do we switch it off.
We estimate in hours, after a phone call and a look at the project. Our latest projects took 15 to 45 hours.
