Our guest poster Amado Candelario is the SEO Manager for Apartments.com, living on the line that separates web development and user experience. He uses data analysis to drive SEO initiatives that maintain and increase organic search traffic to both Apartments.com and RentalHomesPlus.com.
No blog post in the month of January is complete without talking a little about 2012, and I won’t disappoint. 2012 was full to the brim with gifts from all the search engines, and not just the mighty G. Never before has the inbound marketing community been so directly involved with influencing changes in algorithm updates and, to some extent, linked to products created due to the impact of these algorithm updates. Before you start attacking, give me a second to elaborate. I only ask for you to mentally detach yourself from any emotion associated with a site you may have worked on that was negatively impacted in 2012 (this will only hurt for a minute, I promise).
2012 saw the emergence of a new paradigm, one that calls for a slightly more transparent world in relation to search engines. Smaller search engines have been doing this for some time and I want to highlight Blekko for really bringing transparency to the forefront of their search experience. The difference between what the smaller search engines did and what the top search engines did is simple: The big guys gave us invaluable insight into their thought process and gave us access – however cryptic and shrouded in code names – to what they think a better internet looks like. From this, we saw the ever popular Panda and Penguin updates as well as greater importance in the role of UX and information architecture. The latter changes opened the flood gates to a richer web experience for both humans and bots.
Structured data keeps a website protected
Love it or hate it, Google’s algorithm has catapulted over our SEO moat, through the rickety 30 foot walls of Link Building and past the watchtowers of Keyword Research, crash landing atop our perfect castle made of sand. In order to defend ourselves from this assault, we must fortify the information architecture in a way that can withstand the constant barrage and ever changing assault from search engines. The simple, yet underutilized, option is to add HTML markup to the website. So the million dollar question is: Why are websites not using it?
2012 saw the emergence of a new paradigm, one that calls for a slightly more transparent world in relation to search engines.
I think that 2013 will be the year that structured data is incorporated into the make-up of fundamental SEO. This concept is no longer theoretical and, with the ever encroaching mobile threat, it will become increasingly vital to have data and content organized. I am not implying that once markup is added to the HTML rankings will instantly rise or that this is a cure-all for a poor SEO foundation. Structuring the data in a meaningful way reinforces the site architecture by sending clear and concise signals that the data being crawled can best be organized and classified as a schema. The idea here is not to think of structured data as a way to leap frog competitors, but as a tactic to prove a website’s valuable and unique data. After all, we are not talking about investing in unoriginal, shallow content.
How does one get started with structured data?
I can’t speak for anyone else, but I can say with certainty that it’s a big deal to me when the top search engines agree to support a schema for making the worlds information easier to crawl and in return, classify. I want to highlight a simple approach that I took to change the process of how pages are built at my company.
1) Get your best developer on board
This is a no-brainer and, frankly, if you are not best friends with your top dev(s), then there are bigger problems to solve before tackling structured data. Getting this first piece in place will not only provide insight into the realities of marking up the HTML but also carry a lot of weight in the organization when that person is seen in your corner.
2) Evangelize structured data
This second important piece keeps structured data top of mind even when you are not around. This means dropping recommendations in reports or tying the value of HTML markup in meetings (when the topic is relevant, of course) and having conversations about the great attributes available and how they tie to your business. Basically, incorporate markup opportunities into your daily jargon.
3) Find real examples in the wild
This piece ties directly to evangelizing in that you should be taking notes and reporting on examples of competitors or other industries that are utilizing HTML markup. It differs in the sense that this is research driven where evangelizing is all about planting the idea that developing a webpage is incomplete without the inclusion of markup.
4) Keep it fun and pain-free to implement
Don’t be a dictator about implementation by making it all or nothing. This is the last piece of the puzzle because ideally you have collected all the information in the first three steps. Let your developers do what they do best and advise where to best retrofit this idea into legacy code. Most importantly, give them the freedom to get creative and experiment. This is new territory so nothing should be off the table.
Please keep in mind that these are not rules by any means, just a framework that I used to help with the adoption of structuring data on our pages. Depending on the organization, steps 1 – 3 are completely flexible. The only one that doesn’t move is the fourth step, which is all about deliverables.
Case Study: Implementing Schema.org
I want to highlight an example of the fourth step that comes from my own experience of implementing schema.org markup. A developer and I were meeting about the pros and cons of implementing the code on a certain page when he had an idea to create item properties specific to the data we display. I had absolutely no problem with this, and I felt that this is one of the few ways that we could contribute to a better web. I reached out to Duane Forrester via Twitter to ask, in his opinion, would it be worthwhile to add schema tags that do not exist in the main document. To my surprise, he responded and said that the bots would crawl it, but until it is widely used throughout the web it will not be incorporated into the schema family. Nonetheless, the developer wanted to go full speed ahead and we ended up releasing three completely new schema.org item properties for our pages. With Searchlight, I was able to monitor the pages [full disclosure: I am a current Searchlight customer] and I have noticed a small increase in rankings over a few weeks’ time and most importantly, much less fluctuation of said rankings. This has led to an overall incorporation of schema markup on all newly created pages as well as guidelines to retrofit existing code to include schema markup.
I have heard the skeptics, and agree to some extent that structured data sets up websites to be scraped more easily or that search engines are using our precious time to do their jobs for them. Without getting too sidetracked, I want to make the point that if webmasters are complacent with the way search engines interpret their site, then those webmasters should not be surprised when other sites, who put in the work, are rewarded with higher levels of ranking. Gone are the days of “I set up a WordPress site; Google is smart enough to do the rest.”
Chipping at small sections of the site has proven to work the best and doesn’t burden engineering resources as much as doing one large code update. There is no need to markup every single piece of data either, just the important bits that matter the most to your business. Last, boost the benefits of structured data and the security it provides by future proofing your site to your stakeholders.
Everyone’s website is different and companies vary, but hopefully there is enough here to help you start down the path of organizing the most important data on your site. Here’s to another year in the exciting world of inbound marketing…Cheers!
Please note: All guest posts are the opinion of the author and may not be reflective of the views of Conductor.