This series is pulled from a presentation given at SMX East. Part I of this series covered the problems duplicate content creates. Part II covered some of the causes of duplicate content. This post covers some of the solutions that will help you fix your duplicate content problems.
A little over a year ago I wrote an article about how sometimes you have to break a website in order to fix it. This isn’t always the case in SEO but there are those situations where a site is so bad that you pretty much need to burn it to the ground before you can build it right.
The other day I reviewed a site that confirmed this premise. It wasn’t a bad looking site on the surface but once you looked into the architecture a bit you found problems compiling on top of problems. Nothing short of demolishing the entire site and building it from the ground up would allow it to gain any traction in the search engines.
When making changes to my website I always take the time to view them live on the web before closing up my editing software and patting myself on the back in self-satisfaction of a job well done. Even with minor changes, I like to view them one last time to make sure my changes didn’t cause any shifts in on-page display, or I didn’t inadvertently create an error somewhere that inadvertently jacked everything up (believe me, it’s happened more times than I can count!) But regardless of how careful I am to double check my work, there is one thing I almost always overlook; verifying that my site looks good in the “other” browser.
At any given time I have three FireFox browser widows open, each with their own number of open tabs. So it’s natural for me to check and verify my changes using my browser of choice. Sometimes, I even think to check my changes in Internet Explorer. Admittedly, I don’t regularly check IE when the changes are relatively minor, but always when the changes effect formatting. But that’s not the other browser I’m referring to.
We get so accustomed to our own way of surfing the web that we forget that there many other browsers and browsing experiences that may be foreign to us. Now most web designers will do their due diligence and check a site in multiple versions of FireFox, Internet Explorer, Netscape and Safari. Heck you might look at a half of dozen other browsers that most people, including myself, have never even heard of. But those are not the browsers I’m referring to either.
There are four primary “other” browsers and browsing experiences that are typically overlooked by site owners, casual webmaster and, yes, even by the average web designer. But with more and more users moving to these alternate browsing experiences, it is even more important to check your websites to make sure that they function properly for these users.
Yesterday I discussed code bloat by looking at how we can move style sheets and JavaScripts off the page in order to clean the coding up quite a bit. I this third post about cleaning up bloated code I wanted to address Tables and other typical causes of bloated HTML.
Last Thursday I started a conversation about how code bloat can effect your site’s performance with the search engines. Today I’m going to map some specific types of code bloat and very briefly, and non-technically, show you you can eliminate the bloat to improve your pages performance for both visitors and search engines.
There are generally four things that cause code bloat:
During my webinar last month I received a lot of questions both before and during my presentation on website architecture. I’m trying to answer a handful of questions each week until I get through the whole bunch of them. If you have any questions of your own I’d be happy to answer them. You can either post a comment for me to respond to or email me and I’ll add them to the list here.
Today I have answered questions regarding books for beginners, SEO techniques and how they have changed, pro’s and cons of CSS, different types of architecture and favicons.
Lately I’ve been seeing a lot of sites where the designers were a bit lazy on the coding of the visual elements. Especially when it comes to creating new styles for the style sheet. In CSS, it’s pretty easy to develop a style that allows you to have certain portions of text display exactly how you want. But apparently, coming up with a unique style and name is just. too. difficult. So instead of naming a new style, the developers just style an Hx tag and then plaster it throughout the site.
One site that we’ve been working with has just come from a fresh re-design. Once we started digging into the code, we’ve found that the designers have taken some pretty extreme liberties with the Hx tags.
The CSS Anthology: 101 Essential Tips, Tricks & Hacks
Author: Rachel Andrew
Paperback: 400 pages
Cost: $26.37
Published: August, 2007
I’ve never claimed to be a programmer but working in SEO means that I’m involved in creating or editing hundreds of pages over the course of a year. Understanding how CSS works, and being able to implement basic to more advanced CSS strategies, has become essential over the past few years. Until now I’ve only had a rudimentary knowledge of CSS. The CSS Anthology has helped me grow my knowledge significantly on the topic.
(Don't wait for the movie!)
E-Marketing Performance: Effective Strategies for Building, Optimizing & Marketing Your Website Online
