What not to include in a SEO technical report
Working title was how not to write a shit SEO doc
Having been client side and agency side over the years, I have probably read far too many reports from far too many agencies. There are a number of habits from reviewing a number of these, that have significantly devalued them to the client, so if you are writing them yourself, avoid these mistakes.
I asked out on Twitter about common SEO reporting issues and the feedback was pretty swift and immediate. And “rubbish” reports seems to be a hot topic. These guys chipped in, and I would love to say debated, but they were pretty unanimous in their opinions. I would recommend following each and every one of them on Twitter
No offence disclaimer
I should mention of course if I have read a technical report recently of yours, you are not necessarily guilty of any of them, this is a post I have been meaning to write for a while
The most common issues seem to be:
- Fluff before the meat, or even worse: fluff without meat.
An in-depth technical analysis of an issue that doesn’t exist, having read two or three pages of a description of a problem before finding that actually on this site there is no problem, it is simply frustrating. There is a writing style which is an ‘inverted pyramid’ which is used by papers and is especially recommended for report writing. Put the important stuff at the top.
- Poor quality examples
If you have identified an issue, include a couple of examples in as much detail as you need, but if these examples aren’t good then they will devalue the rest of the report. Repeated titles or description tags which are caused by server configuration issues, aren’t a “duplicate title” issue – they are a “duplicate content” issue.
- Using images / text without attribution
Seriously, if you are quoting Moz or Google’s documentation, then please just attribute it. It actually adds real value to the report; whereas using their images and copying and pasting text (without attribution) doesn’t add value. If you write your reports in Word then create a style for external quotes.
- Using overly technical language when English will work fine.
If, when read aloud, you sound like you are talking like a machine, try and refine it, so it is at least readable by the people paying for the report.
- Overstating a minor problem
I have often seen such care and attention to something that ultimately has no impact – if you don’t think it will actually benefit at all, then you are still right to point it out, especially quick fixes, but make sure that you highlight that it won’t have a significant impact. Your honesty and integrity here will speak volumes about you.
- Poor Code
If you are recommending some code, try to make sure it is ultimately reasonable – typos in the code often get replicated on the site, so they can do more harm than good. If you aren’t sure about the code, explicitly say this is pseudo code and so should be interpreted by the developer.
- A lack of recommendations
So what’s next, you tell me I have these massive issues, but what should I do? Make sure you spell it out, explaining why it can be improved and what they can expect to achieve (or how better it will work) when it’s resolved.
- Being insulting and overly arrogant (especially about the developer)
If it reads, “Your developer is clearly a dumbass” and is then sent to the developer, will they be the least bit interested in sorting out the issues? No, he or she will want to defend their position. Simply put, you lose! If the developer becomes a friend and you build a relationship with them (often around the client) you win. Developers are often the guys who will recommend a good agency who understands it from a developers point of view, to a client. That said, sometimes it does pay to be a little assertive and some developers are clearly dumbasses, fortunately these are in the minority and they don’t tend to stay in the industry for too long.
- Wrong client being mentioned
Yeah, you wrote this for client Y, you can save a lot of time by copying it for client X, but you forgot to change client name, this happens a lot and can really wind a client up! The reality is that you are saving them money and being more efficient, but you have left them wondering if the issue you’ve mentioned is really applicable to them.
- Using a tool without insight
Tools like ScreamingFrog and CognitiveSEO are amazing, but if you then just assume the output is correct without investigation – well, you aren’t providing value. You are actually taking value away.
- Unable to print
It will be printed and probably in black and white. If it can’t and is heavy on stock images or looks rubbish on the CTOs desk, they will class it as rubbish.
- Incorrect statements
Check your statement. It isn’t uncommon for me to read through a document and discover issues I know to be incorrect –
The ultimate SEO report contains a number of strong recommendations, prioritised by impact vs effort. Hopefully some quick and easy wins. Recommendations should improve traffic, typically through visibility, click-throughs and indexation, OR it should reduce the risk of suffering from a search engine updated.
It should be easy enough for someone to read who doesn’t live and breathe code but technical enough that a developer can take it and do it.
Some final recommendations
– Create a good template and put fresh eyes on it annually.
– Use blocks of recommendations you have written that don’t mention a client, but can be customised to each client
– Mention what they have done right, but don’t go into too much detail.
– Proof read it (yeah, I know)
– Provide a short list of key next steps or recommendations
– Listen to the business owners or directors; do they have some KPIs, goals or objectives they are particularly focused on? They might already be developing something themselves
As ever, when you are writing something, think of your audience, avoid using geek language and write in a style they will relate to the most. Reference their issues, their site and don’t be lazy – if they pass it onto someone who is an SEO guy (and plenty of people have passed me their agencies reports to read), would they think “this is amazing” or “oh dear, this is utterly awful.”
Anything we missed? Drop a comment below! Think it is worth sharing? – Tweet it!
Distilled have just published a guide on better business documents
No, if at all possible, **get someone else to proofread it**. Even if you are a skilled proofreader, if you wrote it you will see what you intended rather than what you wrote. If you can’t get someone else then print it out – you’ll catch far more typos in a printed document than on-screen.
Totally agree with that. Both points. I find I read what i meant rather than how a 3rd party would read it.
Good list I can certainly agree with.
Regarding the tips, I would also recommend when you do use a client specific variable in a template, use colour and special characters to make it ‘jump’ out of the page #%LIKE THIS%#. End of the day no one likes writing the same stuff dozens of times, but basic errors are….
Personally I think the most important part is highlighting impact vs effort. Also the shorter the report, the better.
I also think the executive summary should explain all the opportunities in a way that a CEO/MD/CMO would understand.