How to brief a developer
on SEO without
getting ripped off.

The rebuild looked great. Clean design, fast load, mobile-friendly. The client was happy. Then three months later they called asking why their rankings had dropped off a cliff. The developer had changed every URL on the site without setting up redirects, removed the schema markup that was there before, and consolidated a dozen service pages into one. None of it was malicious. It just wasn't in the brief.

This is the most common way small businesses lose their SEO. Not through bad intentions. Through a handoff that never mentioned search at all. A developer focused on building what you asked for visually has no reason to think about canonical tags or crawl structure unless you put it in writing.

This guide gives you the exact language to use.

Before you brief anyone: know what you already have

If your site already ranks for anything, even just your own business name, you have SEO equity worth protecting. Before a developer touches anything, you need a snapshot of that equity so you can hand it over as a constraint, not an afterthought.

What to document before any work starts

Export a list of every URL on your current site. Tools like Screaming Frog (free up to 500 URLs) or the free sitemap checker in the DD Tools suite will give you this in minutes. Every URL that currently ranks for something is a URL that must either be preserved exactly or redirected correctly if it changes.

Pull your top-performing pages from Google Search Console. These are the pages generating impressions and clicks. They're the ones most likely to be accidentally broken. Print the list and attach it to your brief as a protected assets document.

Note your current title tags and meta descriptions for those pages. If a developer rebuilds your pages in a CMS without carrying those over, you'll lose months of signal that Google has accumulated about what those pages are for.

The non-negotiables to put in writing

The following items need to be written into your brief explicitly, not assumed. If your developer pushes back on any of them, that's a signal worth paying attention to.

URL structure must be preserved or redirected

If any existing URL changes, a 301 redirect must be set up from the old URL to the new one. No exceptions. This is not optional and it is not difficult. It's a single line in a configuration file. If a developer tells you it's not worth doing for a small site, find a different developer.

Write it like this: "No existing URL may change without a corresponding 301 redirect being implemented and tested before deployment. A full redirect map will be reviewed and signed off by the client prior to launch."

Page titles and meta descriptions must be migrated

Every page has a title tag and meta description. These need to be carried over exactly, not regenerated by a CMS default or left as placeholders. Include the list of your top pages and their current title tags in the brief. Ask for written confirmation they've been migrated before launch.

Schema markup must be retained

If your current site has structured data (whether LocalBusiness schema, Article schema, FAQPage, or any other type), it must be documented and rebuilt in the new site. Ask: "Can you confirm existing schema markup will be preserved or rebuilt in the new build?" If they don't know what schema markup is, budget for someone else to handle that part.

Canonical tags must be set correctly

A canonical tag tells Google which version of a page is the authoritative one. CMS platforms often get this wrong by default. They'll add a trailing slash version and a non-trailing-slash version of the same URL, or allow HTTP and HTTPS to co-exist. Ask your developer to confirm canonical tags point to the correct final URL for every page.

robots.txt must not block indexing

During development, many developers add a line to the robots.txt file that blocks all search engines. That's fine while building. The problem is when they forget to remove it before launch. It's a one-line change that makes your entire site invisible to Google. Include a specific checklist item: "Confirm robots.txt allows indexing of all public-facing pages before deployment."

The red flags to watch for

Most developers who cause SEO damage are not bad at their jobs. They're just focused on a different set of priorities. These phrases in a conversation are worth pausing on.

"We'll sort the SEO out after launch." SEO decisions are structural. Changing URL patterns, page architecture, and schema after a site is live is significantly more work and more disruptive than getting it right before. Anyone who treats it as a post-launch add-on doesn't understand how search works.

"We use [page builder] so the meta tags are automatic." Automatic means default. Default means generic. Generic title tags across a ten-page site all saying the same thing do real damage. Every page needs its own title and meta description. This takes time and it's not handled by a builder.

"Your old site was WordPress so all the SEO transfers over." Nothing transfers automatically. SEO is not stored in a database field that a migration tool picks up. It lives in configuration: redirect rules, title tags, schema, canonical settings, internal linking. All of which must be deliberately rebuilt.

"I'll handle the SEO as part of the build." Unless they've given you a specific list of SEO deliverables with their own line items, this usually means they'll install an SEO plugin and call it done. Get the deliverables in writing before you sign anything.

What to ask for at the end of a build

Before you sign off on any web build, ask for written confirmation of the following. A developer who knows what they're doing will have no trouble providing these. A developer who can't provide them has handed you an unknown amount of cleanup work.

A redirect map showing every old URL and where it now points. If no URLs changed, say so in writing.

A crawl report from Screaming Frog or a similar tool showing no broken internal links, no pages returning 404 errors, and no pages being blocked by robots.txt.

Confirmation that canonical tags point to the correct URL on every page.

Confirmation that Google Search Console has been verified on the new site and that no manual actions or crawl errors are present.

Confirmation that structured data passes Google's Rich Results Test with no errors.

The question that saves you the most trouble

Before any work begins, ask one question: "What's your process for making sure the new site doesn't lose SEO from the old one?"

A developer who has handled this before will describe a migration checklist, redirect mapping, pre-launch audits. A developer who hasn't will give you a vague answer about keeping everything the same or fixing it after.

The answer to that question tells you almost everything you need to know about how much oversight the project will require from you.