• http://WebPieRat.com/ Jill Kocher

    Here, here, Bill! I’m an advocate of better relations between IT & SEO as well. I can absolutely see why the mistrust occurs, when so many SEOs approach IT as if their site is broken. It’s not broken typically; it works just fine for the requirements they were given. But not the SEO requirements, which typically weren’t included. That’s a tricky bit to communicate without putting hard working IT folks on the defensive. We can all do a better job seeing things from their perspective.

  • http://twitter.com/iHealthSci Casey Williams

    It’s all about understanding IT’s point of view… and that it’s not “wrong”. Too often blame is cast when instead it should be a discussion about how we can work together to improve the site as a whole – SEO and otherwise.

  • http://www.adamsherk.com/ Adam Sherk

    Well said Bill, and great point about flawed requirements.

    We’ve found that we often need to take a two-pronged approach to conveying recommendations. A more extensive version that builds the business case and clearly maps out and illustrates the issues and solutions, along with clear instructions on how to implement them. But also as a supplement a more simplified list of recommendations in spreadsheet form can be used to more easily assign responsibility, track progress, reassess, etc. – essentially something that cuts to the chase and can be added into the project plan/roadmap. This is also helpful (along with an executive summary) for those that don’t want to (or won’t) read a 100+ page full site audit.

  • http://twitter.com/incrediblehelp Jaan Kanellis

    Defining requirements for IT walks a fine line.  At some point you have to let IT take the ball and run with it.  I agree simple saying “put canonical tags on all pages” is is an extreme example of far too less of details, but writing requirements to the point where a developer from off the street, with no knowledge of the website, is another thing all together.

  • http://www.ramkrshukla.com/ Ram Shukla

     In past few years search have evolved a lot and Google has added many tools to accelerate the  efficiency of the webmasters. Not only the new but also the old websites should use such methodologies.

  • Devon Butler

    This.  Having both friends and colleagues that are engineers I can say that I’ve seen many of them bristle at a marketer having the presumption of telling them *how* to do something.  Creating a Why is useful from a business case perspective, but be careful how you phrase the How.

  • http://twitter.com/optimizeyourweb Kristjan Hauksson

    When it comes to SEP this paragraph sums it up “Along with small site SEO tactics comes inaccurate or non-detailed specifications. I see too many requests of IT that are simply “add canonical tags to all pages” or “remove parameters from URL’s” with no suggestions on how to do it or a business case for why it should be done.” For me the business case needs to be there and there needs to a clear indication of what the impact is. Great read Bill as always.