Design teams often own typography, layouts, forms and client approval. SEO problems appear in the gaps: retired URLs disappear without redirects, a development noindex setting travels into production, internal links still point at preview domains, or a contact conversion is never recorded. The SEO handoff should happen before launch, not after a drop in organic traffic.
This is not an offer to create another generic audit PDF. The useful work is a route-by-route launch checklist with a clear developer owner, acceptance test and evidence. If the client has an established site, preserve existing high-value URLs whenever possible. A beautiful redesign is not a reason to change every path.
Which launches need an SEO handoff?
A new business site needs crawlability, clear site architecture and working lead capture. A redesign or CMS migration needs a baseline of the live URLs, their replacement pages, and decisions on every meaningful redirect. A site consolidating services needs checks that the new service architecture still answers the old search intent.
Start by classifying the project: fresh build, same-URL redesign, path-changing migration or domain migration. Those are different risk levels. The higher-risk projects also need a rollback plan, owners for redirect rules and a post-launch crawl scheduled before the development warranty expires.
- Fresh build: verify approved service URLs, canonical paths, sitemap, schema and enquiries.
- Same-URL redesign: check accidental content loss, heading hierarchy, core internal links and templates.
- Path-changing migration: document every important old-to-new URL relationship and test redirects.
- Domain migration: confirm Search Console properties, canonical destinations and tracking continuity.
A launch checklist your developer can actually close
Assign each check to a route, template or service. For example, testing only the homepage will not reveal that a deeper suburb page redirects through three hops. The SEO reviewer should be able to point to the exact URL, reproduce the problem and identify the final acceptance condition.
| Check | Evidence to capture | Accept when |
|---|---|---|
| Indexing controls | Robots header and meta directive on live templates | Approved pages are indexable; preview pages stay protected |
| Redirect map | Old URL, new URL, actual response chain | Permanent redirects reach the relevant final URL without loops |
| Forms and events | Test lead ID, source page and GA4 event | Inbox or CRM receives the lead and the event fires once |
| Mobile templates | Representative 390 px and desktop pages | No clipped CTA, hidden fields, or unusable navigation |
| Sitemap and canonicals | Submitted sitemap and rendered canonical tags | Approved URL versions match navigation and response status |
Worked handoff: service URLs changed during an Elementor rebuild
Example: An Australian trades website previously used /services/hot-water/ and the redesign team has replaced it with /plumbing/hot-water-systems/. The old page has local search history. The client approves the new menu but nobody has signed off the URL change.
Capture the old URL and its existing inbound and internal links. Confirm the new page serves the same service intent, update the internal navigation, and set a direct permanent redirect from the old page to the chosen new destination. Then crawl both versions after publication. A redirect to the homepage is not an equivalent replacement for a specific service.
Close the ticket only when the old URL reaches the intended final destination, the new page returns 200, its canonical points to itself, the sitemap includes the new path, and the enquiry CTA remains functional. Attach the response chain and a dated retest record.
What stays with the web design agency
The agency owns the final customer sign-off, hosting plan, approved design, access management and DNS decisions. The SEO specialist can write technical tickets, advise on metadata, verify template output and retest changes. Neither party should quietly modify production without the agreed owner approving it.
If the client uses a page builder, define who fixes what before launch: text and internal links may be editable by the content team; redirects, caching rules and structured data may sit with developers or hosting. A checklist with no assigned implementer is not a delivery plan.
- Agency: client relationship, CMS access, design acceptance, scheduled launch.
- SEO reviewer: source URL inventory, audit tickets, evidence and post-launch checks.
- Developer: approved code/configuration fixes, redirects, forms and backups.
- Client representative: service facts, priority pages, regulatory claims and publication approval.
When not to outsource more work
If the agency has no working backup, no current list of indexed URLs, or no person who can change redirect rules, an expansive SEO retainer will not fix the launch bottleneck. Get those controls in place first. Likewise, do not commission dozens of new suburb pages to replace an established service page just to create more indexed URLs.
A bounded pilot can cover one core service template, one group of redirected URLs and an end-to-end enquiry test. That reveals both implementation quality and whether the delivery handoff fits your agency.
How to measure a successful handoff
Use route-level acceptance, not a promised ranking increase. Record the number of important URLs mapped, redirect exceptions resolved, canonical/indexing errors left open, test conversions received, and post-launch defects reopened. Check Search Console over time for unexpected changes; launch-day positions alone cannot diagnose migration quality.
Request a client-ready evidence pack with the original issue list, approved exceptions, implementation references, final URLs and the person who signed off. This is useful even if a different provider manages ongoing SEO later.
Questions agencies ask before delegating this work
Can an SEO reviewer work alongside our developer without contacting the client?
Yes, when the engagement specifies a white-label workflow. Your agency owns client communication; the reviewer works against assigned tickets and returns unbranded evidence and recommended changes.
Do we need to redirect every old page?
No. Map useful old URLs to relevant new content. Some obsolete pages may properly return 404 or 410; the decision should depend on intent and evidence rather than a blanket homepage redirect.
Can this guarantee rankings after a site rebuild?
No. Launch QA reduces avoidable technical mistakes. Rankings still depend on many factors and can fluctuate during recrawling. The deliverable is verified implementation and a documented monitoring plan.
References and verification
Sources for the platform requirements discussed on this page.