Throughout my career, I’ve worked on web design, development, and marketing teams and have touched almost every aspect of a website relaunch. Today, as an SEO, I see the same common technical SEO mistakes made over and over again. This article explores these mistakes and discusses why it is so important to plan ahead and implement some elements in the beginning of the process « Continue »
Throughout my career, I’ve worked on web design, development, and marketing teams and have touched almost every aspect of a website relaunch. Today, as an SEO, I see the same common technical SEO mistakes made over and over again. This article explores these mistakes and discusses why it is so important to plan ahead and implement some elements in the beginning of the process and not wait to fix them in phase 2.
There are different levels of a site redesigns. These range from a minor cosmetic update to a complete replatforming. Every time a web developer opens up code there is an opportunity to optimize for the search engines. Unfortunately, most web developers simply do not have the time, budget, or the requirements for technical SEO.
Typical Redesign Process
In a typical redesign engagement, a kick off meeting starts the whole processes. This is where the ideas fly. “The site needs to be social,” “we need a way for our clients to contact us,” and “we’d like beautiful photography on the homepage” are typical ideas you may hear at a kick off meeting.
The information architects build the taxonomy and wire frames, the designers bring in the emotional connections, the developers get the site up and functional in the time they have been allotted (which is usually when the project is mostly over budget and their hours have been cut). The site launches and there is a big party. A week later, someone from analytics reports that conversions are up!, but natural search traffic is way down.
How could this be? The site went through 3 rounds of design, development, QA, and it looks amazing. We even had a usability study and passed with flying colors. We are using jQuery and other cool DHTML effects that our users love. Why does Google hate us so much?
The good news is Google doesn’t hate you. The bad news is, during that initial kickoff meeting, SEO was not a big focus. Even if it was, it is usually just talking about keywords and content. I’ve had clients that cut some of the SEO budget to buy better stock photography or to integrate that new analytics system. SEO just falls by the wayside.
Coming from a development background and believing in a more agile philosophy of continual updates, there are a lot of things you can do to help technical SEO after a site is launched. Content tweaks, link building, and internal links are just a few. On the other side, there are a few elements that should be set before any other development is in place. These are URL Stucture, Redirects, Server Headers, and Code Structure.
Four Elements to Lock into Place before a Site Redesign
If the site updates are just design based and every page URL will remain the same, you should be alright. If you are changing taxonomies, CMS system, or programing language, chances are your URLs are going to need to be changed too.
To me, this is the first aspect of a new site’s architecture with SEO in mind. While it is easy to change URLs, it’s not so easy to have Google reassign the value from the old URL to the new URL. If you change a URL from “URL A” to “URL B”, then a couple weeks later from “URL B” to “URL C”, all the value from “URL A” probably didn’t make it to “URL B” and even less value gets to “URL C”. If this was one page’s URL, then this is not a real issue. If you are a large e-commerce site with multiple ways to get to one page, there could literally be hundreds of thousands of redirects happening.
This is why I always start with hammering out my URL structure. This is the foundation of a web page. Set a good foundation and you can build off of it forever. Think of all the possible variations, document them, and make sure developers stick with them.
Quick URL Tips
- Avoid overly long URL’s.
- Have clean URLs without parameters. If parameters are 100% necessary, keep them to only 1 or 2.
- Keep folder structure to a minimum. I try to make all my sites no more than 1 or two folders deep.
- Keep URLs all Lowercase.
- Use hyphens and not underscores for word separators.
I’ve noticed recently that most developers do not fully understand redirects and their affects. I have some clients who still use meta refresh as their mode of redirect. CMS’s like Microsoft SharePoint use the temporary 302 redirect by default. Most developers code redirects for functionality but don’t understand the meaning behind them. To a lot of developers, when someone clicks on “URL A” and gets redirected to “URL B,” the redirect worked. Unfortunately, this is not the case when the search engines spider a website.
The two most common server side redirects are 301 and 302 redirects. As I mentioned above, a 302 redirect is temporary. Think of is as a “We will be back in 15 minutes” sign on the door of a retail store. A 301 redirect is a permanent redirect. Think of that as a sign on the door of a store that states “We have moved to a new location. Our new address is…”
With a permanent redirect, the value that “URL A” has acquired over time will be passed to “URL B”. In the case of a temporary redirect, the value from “URL A” will stay with “URL A”, while the customer will be taken to “URL B.” This may cause indexation issues in the search engines.
- Use 301 server side redirects
- Avoid multiple hops. Redirect “URL A” to “URL C”, not “A” to “B” to “C”.
- Add the redirect commands to the server config file. This will help with server performance.
Server Header Status
Another common mistake I see with CMS systems are soft 404 error pages. A soft 404 is when a customer lands on a “Page not found” type page, but the server’s status publishes a 200 “Everything is OK” message. This can cause a ton of confusion in the search engines and add unnecessary pages to the index.
When a site is relaunched and the URLs have changed, not all pages get redirected properly. If content was repurposed, many times that content contains links with old URLs in them. These cause error pages to pop up. If these error pages are telling spiders that this is an “OK” page and not an error page, the search engines will index these bad pages thinking they are good pages.
On a large scale site, this will cause some issues with over indexing. If your site only has 1000 pages, but Google says you have 9000 pages, you may possibly have an issue with soft 404 pages. This may cause the search engines to think 8000 of the pages are the same and discount your site for low quality.
To be sure your error pages are true error pages, take multiple URLs from your site and remove a letter or two from the filename, folder name, and even the file extension. Copy these broken links and paste into a site like www.URIValet.com or use a browser extension like HTTPfox or Live HTTP Headers. If your pages return a 404 server status message you are fine. If not, you know what to do.
HTML code structure is something that can change once the site goes live, but in reality, it never does. While there may be tweaks here and there, the site’s templated layout is usually set in stone. While in the past I took a harder stance on coding quality than I do now, I still believe starting off with great structure, clean code, and minimal elements will help in the long run. Here are a couple tips I have found to help.
Many developers code in the order they see the wireframes or design comps. This usually means the code order goes something like this.
Structurally, there is nothing officially wrong with this and is pretty standard. The issue lies on the site elements. Many sites have gigantic navigations and sub-navigations. Depending on how much code is in the <head> tag, I sometimes see the first line of the main HTML content land around line 1200 or 1500 in the code.
I personally prefer to have HTML content as close to the opening <body> tag as I can. When I develop a site, I push to have my content above my navigation structures. For example, a site structure I like to see goes as such:
Now the first thing a search spider would see is HTML content.
Having so many calls to a server can slow down page speed drastically. It is faster to download 1 large file then to download that same amount of data but cut into multiple files. The HTTP Request diagram below from WebsiteOptimization.com demonstrates the typical HTTP request. Before the first byte of data is downloaded, the request has to get the IP, open a socket, and wait until the server starts sending the data. Multiply this by as many requests your page is making and you can see where all that wait time comes from.
Quick HTTP Request Tips
- Combine all JS and CSS files into 1 file each
- Minify and gZip these files
- Try using Google’s AJAX File Library
- Minimize the use of images with CSS Sprites
Schema.org Microdata Implementation
This last tip is not for everybody. I am a firm believer in adding semantic code into HTML code, but it is not for every site. Though there are elements on every site that can benefit from Schema.org, I feel e-commerce sites, review sites, and any company that has multiple locations (like retail stores) can benefit the most. Since Google, Yahoo, and Bing all support schema’s, it is the format of Microdata that is preferred.
Schema’s can be added at any time, but in my opinion should be thought about from the beginning of a web redesign. It is easier to structure coding elements at the beginning of development and harder after. It’s not that it can’t be done, but I find that most of the time companies do not want to pay to add SEO later. And that is the theme to this whole article.
Sometimes it is easier and more cost-effective to implement these principals in the beginning of the process. If you wait too long, your site will lose value and your wallet will need to open even larger. Take the time to plan technical SEO from the beginning of the process. Setting a solid foundation to build from is more effective than patching holes later.
This article is not a full technical check list of elements. Feel free to leave any feedback or opinion below in the comments field.