SEO: What Developers Need to Know

by Dan DeMeyere - @dandemeyere

SEO has amassed a bad reputation over the years. Is it legit? Is it snake oil? The truth lies somewhere in the middle. SEO can improve the quantity and quality of organic traffic you receive, but it's not magic. The SEO 'specialists' who suggest building link farms, low-value landing pages, and other shady techniques designed to game PageRank (Google's ranking algorithm) are largely to blame for the negative SEO stigma, but SEO is real and it is valuable.

While there are legitimate SEO professionals who can add value to your website, no one person or department should be solely responsible for SEO. SEO should be a team-wide effort.

Education, authenticity, and diligence should be at the core of this effort. Product, marketing, and development teams should all be educated on SEO and its best practices. It's up to these teams to ensure that the SEO techniques implemented are in the best interest of the user (authenticity) and that the SEO efforts are a continued focus during the construction of your website (diligence).

I recently presented my research and thoughts about SEO to our entire team at thredUP . While the presentation ( click here to view it ) was tailored to a non-technical audience, my focus in this post will be on what developers need to know about SEO.

Google PageRank

It's important to prioritize your development resources to yield the biggest SEO gains for the smallest amount of development effort possible (aka leverage). The first step is to determine your organic traffic breakdown by search engine source. If you're like us, Google is probably your #1 source (over 95% of thredUP's organic traffic comes from Google). Because of this, you should focus on optimizing towards Google's search result ranking algorithm PageRank.

Regardless of whether you're a developer or not, I believe a basic understanding of how search engines work is all that's required to be effective with your SEO efforts. Based on what Google has released themselves and from what other websites have tested and documented, there are widely known and accepted factors that play into Google's PageRank algorithm.

Discovery

Google has to be aware of your website's existence and the content you offer before PageRank can evaluate and index it. Here are some ways to ensure Google finds your content:

  • Manual submission - through Google Webmaster Tools, you can directly add your URL to Google's index .
  • Backlinks - when websites other than your own link to your website and its content, it will provide Google's crawlers another way to discover what your website has to offer.
  • Sitemaps - an HTML/XML file that lists every link you want Google (or your user) to know about on your website.
  • Structured linking - having an organized flow of links on your website allows Google's crawlers to more easily traverse your website and understand the relationships between the content on your website through your links.
  • Product feeds - if you're an e-commerce website, you can send Google your inventory along with meta information through their Google Merchant account center to help ensure what you're selling is showing up in Google search/shopping results.

SEO Elevators

There are certain things that will elevate you above others in Google search results.

  • Quality content - unique and genuine content trumps everything (ex: Wikipedia's quality of content is the reason why they are #1 in search results for almost everything). Google only cares if you're providing value to the user so if a user clicks on a search result and immediately clicks 'back' because the page wasn't helpful, Google knows and it will lower the ranking for the page.
  • Backlinks - the more websites that link to yours, the better your search rankings will be; however, the quality of the backlink is important as well. If a well-known and respected website links to your website, they are legitimizing your website through their own website's PageRank credibility. Conversely, if a small website that is relatively unknown links to your website, the benefits will not be substantial.
  • Best coding practices - being HTML compliant (ex: using alt attributes for images, title tag text for links, etc.), using a hierarchy of HTML elements (h1 tag for page header, h2 tags for sub headers, etc.) and building descriptive URL schemes will further enhance Google's ability to add context to your website's content as well as signal to Google that you take care in the construction of your website.
  • Keywords - if you know the main keywords people are using in their Google search queries for your website, which you can view inside Google Analytics, you can then tailor your meta information content around those keywords to further emphasize their importance.
  • Speed - Google knows how long your page takes to load (Google Analytics) and they know users don't like to wait so the speed of your website will impact your ranking.
  • Usability - Does your website need JavaScript to work? Do you have too many ads? Is your layout conducive to a good user experience? Google's latest PageRank updates include the ability to load JavaScript and CSS to analyze the layout and usability of your website.

SEO Detractors

In general, if you don't follow the best practices mentioned in the list above, you're going to detract from your website's SEO potential. However, there are some things you can do that Google will penalize you for if they find out you're doing. If you want to see an example of how serious Google's penalties are, click here and once the slide loads, click 'i' on your keyboard.

To avoid Google PageRank penalties, stay away from these SEO tactics:

  • Keyword stuffing - if you embed too many keywords into your website's meta information HTML tags, Google will have a tougher time deciphering the signal from the noise. If you really abuse the use of keywords, Google can penalize you for intentionally trying to game the system.
  • Cloaking - putting scrape-able content on a page, but hiding it in from the user is a big Google 'no-no'. Google can load the CSS on your website so they know what content is visible to the user and what you're hiding from them.
  • Low-value pages - creating hollow pages that don't provide a lot of quality content to the user. This is also known as 'content farming'. Good for traffic, but bad for the user. If you create keyword landing pages, make sure you're providing value to the user.
  • Link farms - if you try to 'game' the number of backlinks your websites has by creating new websites that link back to your original website, Google will find out and it will hurt your page ranking.
  • Plagiarism - if you use other people's content, Google has ways of detecting who the real author is and they can issue page ranking penalties if you claim the content as your own.

SEO Summary

Users come first. Google's search engine is designed to give users the information they're looking for as fast as possible. Google doesn't care about your website, it's all about the user so make sure you're building new features for the user and not building features to attract more organic traffic. If you build a genuinely great product for your users and follow best SEO practices while building it, then you'll see results in your organic traffic. Here are some guidelines to follow why you're building your product:

  • Define & communicate keywords - determine what keywords perform best for your website and communicate them to your development team so they know what meta information to focus on (i.e. page titles, meta descriptions, alt text, etc.).
  • URL Naming - take URL naming seriously! Grab a developer and bounce naming convention ideas off of them. When you change a URL at a later date, it hurts the page's SEO juice. 10,000 backlinks to one link is greater than 5,000 backlinks to two different links that end up at the same page. Think about it.
  • Quality content - the copy/content on a page matters. Copy and pasting is the devil for SEO. Be creative, take your time, and make it count.
  • Sitemaps - are you adding a new feature? Make sure you add the appropriate links to the HTML & XML sitemap. Make sure you have FAQ content in place.
  • Don't be lazy - have an image? Make sure there's alt text. Have a link? Make sure there's title text. Use the right elements (h1, h2, p, etc.).
  • Think hard on the meta - when you place the alt text, make it meaningful. If you care, you'll take the time to do it right.
  • JavaScript beware - if a link requires jQuery to work, you're doing it wrong. If a bot can't get from page to page, you're doing it wrong. Disable JavaScript and load your website, the content you want indexed better still be there.
  • Plan from the beginning - before you start coding, think about SEO. SEO can dictate execution (i.e. don't bring content in via AJAX).
  • Natural feature flows - does the feature flow intuitively? Is it organized? Is there a hierarchy? Can you a build a directory page for it?
  • Don't be shady! - Google doesn't like it. Developers don't like it. It feels dirty-all-over to code something that does not benefit the user and has negative, ulterior motives.

If I missed anything or you disagree with my conclusions, please comment below.

Responsive Web Design

by Dan DeMeyere - @dandemeyere

I've been waiting to write a post on responsive web design (RWD) for a long time. I think it's a really powerful tool for websites that care about usability and UX. Definitions for RWD vary depending on the source because it's a relatively new 'technology', but I would describe it as developing a website in such a way that the layout/look responds accordingly as the browser changes by dimension or by device.

There's an important distinction to make about my definition. Just because a website looks different on a mobile device than it does on your computer, doesn't necessarily make that website responsive. A lot of websites detect whether you are viewing the website on a computer, phone, or tablet and either serve up a separate CSS file specifically built for that device type or they might even serve up a completely separate mobile version of their website or application.

For example, if you use 37signals' Basecamp product and you login on your computer versus logging in on your phone, you will be using their product on two completely different development frameworks. I don't doubt that they use some responsive elements in their design, but RWD is when it's the same exact website that uses a combination of specific RWD techniques, such as media queries, to alter your client-side interaction while the server-side code remains the same.

It should also be noted that RWD isn't for all websites. If you have a very large website (i.e. 50+ pages), it's going to be very hard to make all those pages responsive with any continuity without sinking an excessive amount of time into it, especially if your layouts differ from page to page. It also adds overhead in the sense that any design change require another level of upkeep and quality assurance.

If this still isn't making sense, I listed a couple example below that illustrate what RWD looks like in action.

The most simple use case for this is adding it to your personal website. A really good example of RWD in action is Joni Korpi's personal website. I meant to write about Joni Korpi in my web designer portfolio post, but his three-tier responsiveness was too perfect for this one.

If you look at the picture below, you'll notice there are 3 different layouts to his website. Each layout corresponds to a certain browser dimension. If you go to his website (it's been re-designed since I captured the images) and re-size your browser to those dimensions, you'll notice the website's layout/design changes on the fly - it's pretty cool.

Next up is the French Earth Hour conference website. On a quick tangent - I think the colors of this website are awesome. Anyways, I only noticed two different responsive designs for this website as you see below. For some websites, that's all you really need. The creators of this website probably only wanted to optimize the design for full-width and standard mobile dimensions; I'm guessing this is the case because people typically hear about a conference through email, social media (both viewed in full width browser) or through oral referrals away from the computer (mobile browser). Something especially cool about what they did for their second layout (the one on the right) is that they removed some elements of the page to ensure the most important content was still above the fold - sweet trick.

Last, but not least, is Trent Walton's blog. Websites that contain content that can be consumed on multiple mediums is the most natural need for RWD in my opinion. I spent a good amount of time inspecting the source/CSS of Trent's blog as it was very helpful for building my new website's layout in a flexible and fluid way that is optimized for RWD.

As I just mentioned, I'm currently re-building my personal website, hence the lack of posts, but one of the first things I'm going to do once it's finalized is start working on making it responsive - which I'll attempt to document the best I can for another post. If you're looking to make your website responsive, I would check out the following posts:

Working for a Start-up: Developing Outside Your Demo

by Dan DeMeyere - @dandemeyere

When you work at a start-up, you're not given a bulleted feature spec. document detailing every design detail, each UI interaction a user will experience, or how every page of a feature is supposed to flow. Although it can vary, you're usually given three things: what the feature is, why we are building it, and basic expectations of the deliverables. Some people find this overwhelming. I, however, wouldn't want it any other way.

The freedom of taking a feature concept and turning it into a functional aspect of your web app used by thousands of people every day creates a certain level of responsibility that is intoxicating.

Every decision is important. Deciding how your feature will hook into the current app on the back-end, how users will navigate to your feature, etc. are all decisions you need to work through on your own and they typically require a decent amount of thought. The easiest way to go about this is putting yourself in the shoes of your user and asking yourself, 'if it were me, how would I expect this feature to behave?' But what if you can't put yourself in the shoes of your user?

thredUP.com's demographic is comprised of over 99% women. 100% of thredUP members are parents. One could make a very strong argument that it's not possible for me to be further from our demographic, yet I develop for thredUP every day and build features that our members enjoy (I hope). So what are some of the tips I use?

Align Your Perceptions

If you're not a power user of your service, find one and talk to them. My CEO is a parent of a 9 month old girl and he uses thredUP for almost every piece of clothing she wears. Because of this, I can pick the brains of one of our super users without leaving the office. I might think a feature is great, but then again I don't have children and I'm not using the service out of necessity so my perceptions aren't really aligned with reality.

Another great way to ground your assumptions is to do customer service. Talk with your users. See what problems they are having and what isn't obvious to them. Something you think is intuitive might be confusing to your user. I live in a world of Macbook Pros, iPads, Androids, and know what AJAX is and how it should behave. However, over 47% of our members use Internet Explorer and some of our users are notorious for 'double-clicking the internet'. This is why we've started disabling buttons once you have clicked them and display activity spinners every time an AJAX call is made to let our users know the service is processing something. Intuitiveness is relative. The dichotomy between Windows users and Mac users is sizable enough where you can't assume that a behavior you find second nature on your iPad won't be obscure to half your users.

Use Your Service

This might sound ridiculous, but you have to use your service as your members do. If I worked at Quora or Twitter, two services I use and enjoy, this wouldn't be an issue; however, some of us work and develop for services that are not intended for us. This shouldn't stop you from experiencing your service the way your members do. For example, I pick and list boxes at thredUP and I even have a public profile on our website. The last time I listed a box, I found myself noticing how 4 steps should really be 3 and that an email I received wasn't as helpful or descriptive as it could be. These are the things that help you avoid developing blindly and building features no one will use.

Of all my tips, I fall victim to this one the most and it's probably the most important of them all. My bosses emphasize doing this on a regular basis and I'm grateful as it's important to discover the pain points of your service first hand.

Metrics, Metrics, Metrics

Figures don't lie, but liars figure ~ Mark Twain

Have you ever gotten into an argument where someone states something like 'all of our users ' or 'no one uses ' and you know they are wrong but you can't prove it? This is why you need to become friends with metrics. If you can't pull them yourself, find a developer who can and ask them for a specific data-set. Sometimes the easiest way to do this is to tell them exactly what you're hoping to derive from the statistics. Translation can be lost between models/databases and the names of features thrown around the office. A good developer should be able to find conclusive data for the metric you're looking for.

Solid metrics with proper baselines can save you from arriving at the wrong conclusions. I wish I did this more, but benchmarking all your features after enough time has passed to collect a valid sample set of data is foolish not to do. I sometimes say to myself 'if only I had more time', but that's just a lazy statement. You could run one query that takes you a minute to write that could save you days of development. One great example of this is when we launched a new homepage design that we all thought was amazing, but the metrics disagreed. The homepage had notably worse conversion rates and it became apparent that we had to move on and figure out why our development assumptions were off. I actually wrote about the dilemna we faced and the art of swallowing your pride and admitting when you're wrong. Which leads me to my last point.

Know When You're Wrong

If you're not in your demographic.
If you're not a super user of your website.
If you don't have metrics to back up your assumptions.
Then you have to face the music.

The fastest way to lose an argument, lose your leverage in arguments, and lose respect is by making unfounded statements. Bite your tongue unless you know what you're talking about. Before you go into a meeting and discuss the conception or evolution of a feature, think out your reasoning and be ready to back it up with something undisputable (metrics) or personal experience with the matter (user stories). Maybe your still wrong, but you won't lose respect if you're prepared and you're offering conclusions on valid assumptions.

Minimum Product Strategies

by Dan DeMeyere - @dandemeyere

When you're creating a new feature or adding functionality to your web app, you typically don't have time to dive into the minutia of every aspect of how the feature will look, behave, and function. Obviously you can indulge yourself into that level of detail, but it is typically the most time consuming aspect of a feature and it shouldn't be tackled until the minimum required functionality of the feature is complete.

If you get caught up in the sexy or fun part of the project, the user-facing portion, it's possible you'll use all of your allotted time for the project carrying out non-critical feature development and you won't be able to release anything as your feature still isn't functional. If you develop in such a way that you make the feature usable and functional first, you can spend all the remaining time layering on the subtleties of good UX. If things go wrong and you end up having very little time to layer on the aesthetics, at least you can release the feature and come back to the subtleties later. This strategy for building features is commonly known as Minimum Viable Product (MVP).

I am a very big proponent of developing with a MVP mindset. If I'm given a 3-day window to work on a project, I'll determine what the MVP and critical path for that project is within the confines of 3 days. With this mindset, my only enemy is scope creep. Scope creep is inevitable with every project and unless it's absolutely necessary, my natural reaction is typically 'great idea, but it should probably go in version 2 of this project'. This approach is a double-edged sword. Because I take this stance, very rarely are my projects not completed by the designated time; however, it's possible that the MVPs I develop are too bare-boned to be a feature that users will be delighted by. This is where we enter a gray area.

I can go the extra mile and try to delight the users, but then I will run the risk of spending too much time determining what I think the users will perceive as delightful, which is highly subjective and not always obvious. It leaves a certain level of uncertainty in determining the completion of the project that I'm not comfortable with.

The concept of building towards a delightful product, or Minimum Delightful Product (MDP), was coined by either James Reinhart or Oliver Lubin, I can't remember which. Respectively, they are the CEO and CCO of the company I work for - thredUP.com. MDP is a very forward-thinking strategy to product development, but I'm going to go against the grain and disagree with my bosses and their concept. Before I do so, I want to elaborate on the idea of MDP.

I believe MDP is the evolution of another strategy that bares the same acronym, Minimum Desirable Product. Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users. That definition is a direct quote from Andrew Chen's aptly named blog post 'Minimum Desirable Product'. In this post Andrew Chen (@andrewchen) explains that MVP tends to center around the business perspective of a feature and what you really need to focus on is what feature your users desire.

What my co-founders argue in favor of building for delight over desire is that sometimes what users want (desire) is different from what will actually 'wow' them (delight). If users were able to add every feature they desired, you potentially could end up with a cluttered product. While there are many examples of this, my favorite is the homer-mobile. Homer Simpson once created his dream car with every bell and whistle he could possible want, but it ended up looking like this:

I could also demonstrate the other end of the spectrum by showing a product that succeeded in ignoring feature requests and still delighting their users - the Apple iPad. Users wanted Mac OSX on the iPad and countless other features, but Apple determined the core experience they wanted the iPad to emanate and built towards that while letting many features fall by the wayside. I think we can all agree that the iPad has been a smashing success and the simple experience and usability is a fundamental reason why. I'm not saying that building for what users desire leads to building cluttered apps, but there's definitely a gap between what users desire and what will delight them. Because of this I believe there is great merit to the Minimum Delightful Product way of thinking. So why am I hesitant to buy into it then?

The reason why I am hesitant is that 'delightful' is a very subjective term and assuming you know what the users will consider delightful is a bold statement. Outside of Apple and a few other companies, most struggle with always delivering a delightful experience and if you're not in your product's demographic (like myself), it becomes even harder to identify what will be delightful for users before the product is built. I'm not saying building a Minimum Delightful Product is wrong, I'm just saying it's difficult and you're bound to arrive at the wrong subjective assumptions every once in a while.

I don't believe in criticizing without offering a solution, but my spin on the strategy is kind of a cop-out as I believe the right approach is a balance of all three. Obviously the complexity of the project and resources available will always dictate your flexibility on strategy, but in the optimal environment I would prefer to build an MVP that is structurally sound on the back-end and then put a thin layer on top that will elevate the feature to what the users desire while showing glimpses of how version 2 of the feature would delight them. It's basically right in between building desirable and delightful product.

With this approach, you are less likely scrap work made on inaccurate assumptions. The only requisite to my approach is you have to schedule version 2 of the feature very soon after version 1 is complete. If you don't bake V2 into the schedule right after V1, I doubt you'll come back to V1 and ever make it a delightful feature for your users. Build V1 -> collect feedback -> adapt the feature -> release V2. It's eerily similar to the 'MVP -> release -> iterate' agile workflow, but somehow in my head it's different in all the right ways. I think I'll call it the Minimum Dan Product so I can have another MDP acronym to be confused with.