How to Write a SEO Brief That Gets You Understood (and Not Cursed)

SEO folks, be honest – how many times have you written a brief? Pretty much every day! And how many times have you then caught facepalms from your team or seen disappointing results? Exactly. It almost feels like our fate is to draft briefs for everything: for content, code, design, internal linking, error fixes – the list goes on.

What Exactly Is This Brief?

It’s a technical assignment. Not some scribbled note on a napkin, but a proper document. Usually a Google Doc, because who still uses Word for this? The idea is simple: you (the client – often the SEO person) write down what needs to be done, and someone else (the executor – a developer, copywriter, or It makes no sense. It’s always for someone else. And yes, we’re talking about online projects here, not blueprints for a lathe – even though there are standards for that too.

What to Include in a Solid Brief So You Don’t Look Like an Idiot

• Goal: What’s the point of all this? It should help the executor understand the context, not just randomly press buttons.
• Task Description: What exactly needs to be done? Provide clear instructions – no fluff, but also no hidden details.
• Links and Exports: Include examples of what should be done (and what shouldn’t), official documentation, validators, and any exported data from parsers (if applicable). Don’t make people waste time searching for what you already have.
• Implementation Examples: “This part is done well here, so do it the same way.” Priceless.
• Desired Result Format: What final deliverable do you expect? A text document? Site changes? A spreadsheet? An image?
• Deadlines and Executor Information: Optional, since this is often handled in your task manager.

Metrics for the Perfect Brief (My Favorites):

• The “Any Random Joe” Test: If someone who’s not involved in your project reads the brief and understands what, why, and how – this is a win.
• The “Silent Executor” Test: You hand over the brief and then – silence. Not a single follow-up question (or maybe just one), and the result is exactly what you wanted. That means your brief is on fire.

Why Do SEO Specialists Write Briefs Non-Stop?

Because we hardly do any hands-on work on the client’s website. Our job is to brainstorm, analyze, find growth points, and – yes, you guessed it – write the technical assignment for those who will implement it.

• Brief for Content/Rewrite: Include volume, keywords, structure, originality, headlines – everything.
• Brief for Microdata: For the developer – explain what goes where, which syntax to use, and how to verify it.
• Brief for Designers: We don’t decide if it’s green or purple, but we do determine which blocks go where. Sketch a rough prototype with boxes and add examples.
• Brief for Page Creation: Is it a mass-generated page or a single page? Where does it go? What template? Where’s the content coming from?
• Brief for Internal Linking: From where to where, with which anchor texts, as a new block or inline?
• Brief for Fixing Technical Errors: Found 404s or issues with redirects? Gather them together, describe how to fix them, and hand it to the developer.
• Brief for Meta Tag Templates: Create a template, explain its logic, variables, and applicable pages – then let it be implemented.
• Brief for Generating Alt Texts: To avoid manually writing alt texts – ask the developer to automate it based on set rules.
• Brief for Implementing a Block: Want a testimonials block? Describe its components, where it belongs, and what content it should contain – done.

And that’s just the tip of the iceberg!

Main Pitfalls When Creating a Brief (Don’t Step on These Landmines!)

• Not Writing a Brief at All: “Hey, Joe, something’s broken – fix it.” Classic. Never do it.
• Assuming Something Is “Obvious”: FORGET THE WORD “OBVIOUS”! Imagine the executor is an alien who just learned about the internet yesterday. Or picture someone who’s looking for any loophole to do things his own way, while still technically following your instructions. Write for them.
• A Brief Without a File Name or Site/Page Reference: The executor opens your “Untitled Document” a week later and wonders, “Which one of my 50 projects is this for?” Always specify the domain and exact page if needed. It saves everyone time.
• Not Stating the Goal: A missed opportunity. The context helps the executor make the right decisions if something goes off plan (and it will).
• Being Stingy with Links: Didn’t include a link to the referenced page? The official documentation? A validator? A sample site? Come on – don’t force people to waste time searching or guessing. It’s just rude and counterproductive.
• Not Providing Implementation Examples: Especially for complex tasks. “Look here, do it like this” is often the clearest way to explain.
• Omitting Exports: Parsed the site and found broken links? Provide a link to the file with your data! Don’t write, “Go parse it yourself and fix it.” That’s bad form.
• Avoiding Pictures: Screenshots are your friends. Even an obvious screenshot simplifies understanding. Use them wherever possible.
• Unclear Deliverables and Verification: What should the final product be? How do you know it’s done right? Who checks it? At least give some hints.
• One Brief for Multiple Executors: Dumping tasks for a developer, writer, and designer in one file is a recipe for confusion. Write separate briefs.
• Unachievable Items: Asking for an employee photo when you don’t even have one? Why? The developer will push back. Remove from the brief anything you don’t have the resources for right now.
• Vague Wording: “Get rid of broken links.” How? Remove them? Replace them? Redirect them? Be explicit: “Remove the broken links (list here: [link]) from the article text (link to article).”
• Using Names Instead of Roles: “Ask Petey.” But what if Petey’s on vacation or has left? Write “Check with the frontend developer.” It’s much clearer who should be contacted.
• Excessive Freedom: Letting the executor choose how to achieve the result is fine – but you decide what exactly the end product should be and by what criteria. Don’t let them decide to remove a page or not if the instructions aren’t crystal clear.

How to Whip Up a Brief on the Fly (A Mini-Example):

Suppose you need to quickly create a testimonials page by pulling in reviews from external platforms.

• Header: Company logo (if you have a standard one), date, Title: “Brief for Creating the Testimonials Page.”
• Site: https://max.nardit.com
• Goal: Create a /reviews/ page, pull in testimonials from platforms X, Y, and Z, and add a block with links to other review sites. Help Google reviewers gauge our reputation.
• Meta Tags: Specify the Title and Description for the new page.
• Structure:
  • Display an H1 that reads “Reviews About Us.”
  • Pull in the latest 5 reviews from platform X (include a link). Arrange them in blocks. Add a link saying, “Read all reviews on X.”
  • Do the same for platforms Y and Z.
  • Add a block titled “Read reviews on other platforms:” with clickable logos linking to platforms A, B, and C. (Ideally, download the logos and attach them, but if the developer is nice…)
  • Flowchart: Draw a simple layout in Miro or Draw.io showing where each block goes. Attach the link and a screenshot.
• Important Details:
  • Page URL: /reviews/
  • Add a link in the site’s footer.
  • Don’t involve a designer – use standard admin blocks.
  • Create it as a draft and send it for approval before publishing.
  • Table of Contents: Insert an auto-generated TOC at the beginning of the document for easier navigation.

That’s it – you can hand it over to the developer. Of course, you could write this brief in ten times more detail, but if you know your executor and are confident they’ll understand, why waste extra time? Time equals money.

Writing a brief is like walking through a minefield. One misstep to the left or right – and either the executor doesn’t understand a thing or they deliver something completely off the mark. The key is to think ahead for them, anticipate their questions, be as clear and specific as possible, and don’t be afraid to add an extra screenshot or link. Trust me, this saves a ton of time and nerves later on. Maybe then, business mishaps caused by miscommunication will be a little less frequent. Good luck to all of us in this tough job!