SEOs Should Understand Network Infrastructure

As an in-house SEO, you need to interact with senior engineers, project managers, and analysts who know your infrastructure and its limitations inside and out. Adding an understanding of your network infrastructure to your SEO knowledge base gives you the right lingo and frame of reference for conversations with techies to help you gain coveted […]

Chat with SearchBot


As an in-house SEO, you need to interact with senior engineers, project managers, and analysts who know your infrastructure and its limitations inside and out. Adding an understanding of your network infrastructure to your SEO knowledge base gives you the right lingo and frame of reference for conversations with techies to help you gain coveted respect from the IT department. Knowledge of your network can open doors to complex decision making conversations that SEOs need to be part of.


Who to talk to: Ask for a network overview from one of your senior architects who can answer specific questions and use everyday language to describe technical concepts. While you could meet with a network engineer, I recommend you meet with an architect on your website development team in order to simultaneously cultivate relationships where you need them most. You may find that a project manager wants to give you this overview, but my experience has been that many project managers don’t really understand the big picture. You really should push for talking to an architect with in-depth knowledge of the network, who can answer your questions and potentially give recommendations for a new way of approaching your concerns.

If you find IT is resistant to this conversation, it could just be that they have a full workload. However, if you have a history of poking holes at IT’s work, you might be getting pushback because they don’t want to deal with SEO criticisms and change requests. If this is your scenario, ask for the meeting by saying that you want to better understand how things are set up so that you can make recommendations that will work within your current environment.

What to ask:

  • Can you draw me a picture of the network? You want to walk away with a diagram of the network, which boxes are used, what each box is called, how they connect to each other, and how they are related to the website. This will serve as a reference for the remaining questions.
  • What type of servers you do use (Apache, Unix, etc.) and where are each in the network? This can give you insight into some of the limitations for redirects and more.
  • What route does traffic take from the moment it enters your network until it reaches the web servers? This portion of the conversation has two parts. First, ask how users/people are routed through the network, then ask how search engine robots are routed. Some companies send the search engine robots to specific servers, and send users to one of many servers for load balancing.
  • If your website is replicated on many servers, do you display different versions of the website on each? One reason for doing this would be for A/B testing. If you do display different versions on each server, find out whether or not the A/B versions of the site are being shown to the servers that search engine robots may crawl. If the answer is yes, you will be concerned about the types of changes being tested and how they are coded. Sometimes A/B testing is done for quick-and-dirty testing because it is live for a short amount of time. Ideally, these versions of the website will not be displayed to search engine robots.
  • If you have multiple websites, how are they are handled in your environment? Do they sit on different servers? When is it determined that traffic is routed to each server?
  • When are redirect files accessed? Sometimes redirects are done before the user hits the application; other times they are done after the user hits the application. Most likely you will have a combination of the two, and you will want to understand how and when each are used so that you request the right redirect when you need it.

Ask questions when anything doesn’t seem clear. I once probed and probed because my gut said something was fishy. Before I knew it, the architect said, “Well, there is a script that every user agent goes through that sends the users over here, and sends search engine robots to pages that sit over here. These are .html files that were created several years ago by a consultant. It was part of the old site, so we carried it over in the redesign.” My jaw hit the floor when my eyes were greeted by the ugliest cloaking pages ever seen—complete with bright pink background and every single competitor name in large bold font.

Do you need the detailed infrastructure knowledge to do SEO? No, but it is helpful. I’ve done SEO on several sites not knowing this information. However, when you’re in-house it’s a completely different ballgame. You have to interact with developers and need to earn their respect. Knowing about your infrastructure makes it easier to follow developers in conversations and, in time, you have the knowledge to intelligently participate in technical conversations using IT lingo. I have found that this earns the coveted respect from IT, and earns invitations to the meetings where IT makes decisions on things that will make or break your SEO efforts.

Jessica Bowman is the Director of SEO for Business.com and an independent consultant and author of the SEM / SEO In-house Blog. The In House column appears on Wednesdays at Search Engine Land.


Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.


About the author

Jessica Bowman
Contributor
Jessica is the In House SEO Adviser for Search Engine Land and a member of the programming team for SMX events. She is the founder and owner of SEOinhouse.com, a company on a mission to make in house SEO simpler. She is a leading advocate of in house SEO, and started in house SEO programs at Enterprise Rent-A-Car, Business.com and Yahoo! Inc.

Get the must-read newsletter for search marketers.