Proper SEO techniques will allow humans and robots to see your site

There is always a conflict between how accessible your website data is to Humans and to Robots.  The ability to “convert” a human to finalize a purchase is paramount so keyword spammy webpages that reduce conversions are simply not worth it.  However you also can’t convert humans unless the #1 lead source to your website is being catered to as well, whether overtly or behind the scenes. 

This method of targing both the human conversion and the robotic discovery is accomplished by implementing proper SEO techniques.  Many people ask me what the “trick” to Google is.  I can summarize it very succinctly.

TELL THE TRUTH

Google can spot a fake and if you are going to rely on black hat tricks and schemes, you’re simply going to see a short-term boost in ranking which will wither on the vine.

Humans and Robots have different needs

The example on the right demonstrates a clone avoidance technique using the NOFOLLOW rel parameter on anchor text (<a href> hyperlinks).  In a traditional website we tend to let Google see EVERYTHING which is not effective.  Think of a typical brick and mortar store.  We have a nice front entrance with customer-oriented displays that are less organized but are beautiful and pleasing.  We also have a back door that opens to highly organized inventory warehouse with bare cement floors and barcoded shelving units. 

Humans should enter our website through the front door and see things like the customer service counter and the privacy policy and featured items… and the checkout aisle.

Robots don’t need to see any of this.  They aren’t going to buy anything, they don’t need to see our investor information, and they don’t need unorganized but pretty FLASH movies or glamorous pictures.  Not only can they not see them… they simply don’t care.  The diagram above illustrates how we set NOFOLLOW on portions of our website that may be visible to humans but we want the search engines to ignore them. 

Avoid Cloning through NOFOLLOW

We also want to ensure that Google indexes our website in the proper order and we channel the “juice” as concentrated as possible to our “money pages” and the hierarchies that go with that.  Take a product where the customer can navigate there in two separate paths.  They may come to my Nike yellow tank top through /Nike/Tank-Top/Yellow or through /Tank-Top/Yellow/Nike.  This creates two separate URL signatures that land on the same, exact product… effectively a clone.

To avoid this, we set a “weight” on each parameter as to its importance.  In this case we believe that more conversions will be determined by Brand and then Type and then Color.  Any other “path” to this item is “NOFOLLOW” enabled so Google will only see the one path… however the humans will see both.

Protecting your paths will ensure SEO dominance and conversions.

Moving Your Website to a New Location?

When you move your business, you make sure that you shut down your utilities, forward your mail, change your billing address, and above all, you make sure that you put up that nice sign in the door that says to any loyal customers that may be returning that you have permanently moved to a new location.

This “permanent redirect” is a very special instruction that is also used by Google to identify pages that have moved their location as well.  Online a “street address” is a website “uniform resource locator” or URL.  You type in URLs all day when you enter in addresses like http://www.google.com/ or http://www.fuzion.org/.  What most people don’t understand is that every single “landing page” on your website has a similar address that is a bit more complicated such as www.FUZION.org/Web_Marketing for example or even more complex:  www.Tire.biz/page/Tires.aspx.    Many people will “bookmark” a home website address, but often enough they bookmark pages deep in your site with these complex URLs.  We call this “deep linking”.

These deep links are very valuable because, compared to your homepage there are hundreds of times more of them, and they tend to be links that reside on message forums (“Hey, check out this item”) or are linked in web email client systems (links in Gmail, Ymail, or Hotmail).  Because these links come from very high page rank value (PR value) websites, they are extremely powerful and should not be abandoned lightly.

Normally when you update your website with a new look, or a new content management database, the “home” address or “root” address (http://www.yourwebsite.com/) rarely changes… and when you move to the new site you think your work is done.  However, what actually has happened is you’ve lifted up that business building, severing all of the existing customer relationships, bookmarks, and back links to your business (or website) to deep linked pages (www.YourWebsite.com/page/specificpage.aspx) like wires and pipes dangling beneath it and you’ve dropped in a brand new building at the same address.  What’s actually happened is that all of those severed wires are still there… only now they go to web “dead ends”.   If you compare the diagram to the right.

Customers that liked your website enough to bookmark a very specific page are now finding dead links and frustrating error messages which makes them sever the link completely.

Forward Your Phone Number

It makes sense then to use a tool built into web servers called the 301 Permanent redirect or the 302 Temporary redirect.   These two tools allow you to permanently move or temporarily switch pages and notify the search engines that you want them to “forward” the customers while preserving the history and value that has built up over time in the search engines for that page’s value.

Forwarding makes a lot of sense because now, a customer that had a URL “bookmarked” will be redirected to the new, replacement page.  Search engines will also start the slow process of transferring the original pages PR value to the replacement page, giving you a nice boost in your search engine rankings for your new pages that would have taken a long time to earn a new ranking.

It’s Not Too Late

Already done a remake (or two) on your website without doing the proper redirects?  It’s not too late to fix it.  Just install Google Webmaster Tools - www.google.com/webmasters/tools and verify your site.  This tool is provided by Google which will give you a listing of all of the “404 not found” errors found on your website.  They will also let you know which websites are linking to each page and will help you find ones that you may have forgotten.

You can load 301 Redirects into your htaccess file if you are using Apache webservers or you can install the IIS 7.0 URL Redirect plugin and modify your URL mappings in the IIS editor or directly in your Web.config file.  If you are using IIS 6.0 you can install an ISAPI URL Rewrite handler and edit the .ini file for those as well.  You have invested in your website over time... don't throw it all away by not forwarding the traffic to your new pages!

12-Forward-Your-Phones-When-You-Move.pdf (206.68 kb)

Atomic Data makes search engine dominance possible

Online retail is not the same as brick and mortar retail.  When a brick and mortar store launches online they fall into this biggest trap.  Take an apparel shop… when you first walk in you find a men’s department and a ladies department.  The store is physically trying to demographically segment you.

If you create a data model that matches this, you will end up with the first <xml> node being <gender> which is a highly limiting path to follow for a search engine even though it may make the most sense for a human being.  You would then add data for teams, sports, colors, sizes, variants, materials of manufacture, and many other “parameters” for this data.  To avoid 3rd normal database limitation, you would start to peel this data out into separate tables… one for colors… one for teams…one for sports.  Then you would need to create many-to-many crosslink tables.  Over time, your table count just gets larger and larger as new needs arise.

The Root Object Classification

There is certain data that “hangs” off each sub-classification.  In this example the Item class stores who the manufacturer is (because most items have manufacturers).  The Apparel class contains the style information (because style is global to all apparel objects), whereas the Shirt class contains collar styles, sleeve variants, etc.

By localizing this information to class levels, once I define a “field” for the Apparel class, all future objects that inherit from that class will inherit that field.  Any objects that do not inherit from the Apparel class will not have the field at all.

Note how different this is from a traditional 3rd normal representation of data where we would have fields like “color1” and “color2” and “color3” simply to leave enough fields available just in case we might need them for a particular product application.

Maximum Flexibility for Customer Paths

Now that our data is structured with infinite flexibility while still retaining a core hierarchy (for default navigation purposes), when a customer walks into our store, we can simply ask Google “how they sent them” to us… and what keywords they used.  Now when the customer enters our “store” we can toss all of the inventory up into the air and literally rebuild our store to match the words they used in the order they used them.  Now they can enter as “ladies yellow tank top” and we structure our product data in terms of gender first, color next and product class third… but we also can welcome customers that ask for “white womens Nike shirt” which we do by scanning for aliases of class nodes, parent classes, and other permutations of the item for maximum comfort to the customer and higher conversion rates on sales.

Know a business that would benefit from our whitepaper on how Atomic Data Modeling can make search engine optimization possible?  Download it now:

02-Atomic-Data-Enables-Search-Engine-Dominance-by-FUZION.pdf (369.99 kb)

They call it a website for a reason

Most first-time websites are designed with some flawed theories in mind.  The theoretical flaw is that the homepage must lead the customer quickly to what they were looking for which assumes that the customer enters at the homepage and then discovers what they need by clicking.  This “rapid funnel” concept is based on the idea that a customer doesn’t have the patience to “click through” too many pages and the site should be designed to streamline that as much as possible.  While the idea has some merit for the customer interaction, the biggest flaw is that customers simply do not enter your website through the homepage at all (at least the vast majority of them).

The Homepage is the Least Important Page of your Site

We will use the www.JaxTires.com website as the example to illustrate this.  If a customer owns a car in Jacksonville, Florida, they might think to type in www.JaxTires.com, but the vast majority are simply going to visit Google and type in “new tires Honda Accord” to find the specific product that they want.  If a website were a funnel, we would force them to enter at our homepage, click on Vehicles, then Honda, then Accord, then Tires.  In actuality, they click on Google, enter their search, find the results, and then they land directly on the specific item page for the Honda Accord at www.JaxTires.com.  Instead of the website funneling the traffic to the specific page, the tens of thousands of specific pages expanded out from the center like a web, trapping the web surfing customer with a highly specific keyword that best matched their search.

You can see now how the homepage’s job is not to be all things for all people… It’s simply the very center of the web that spawns out threads in circles around it in a web form with the purpose being to “capture” every possible web searcher and land them on the most specific, most highly targeted page.  The larger the expansion of that web and the more comprehensive the possible combinations, the more apt your website is to trap the flies that are buzzing around.

The Most Lucrative Keywords are the Most Specific Ones

Let’s take a look at an alternate way of looking at a website.  Here we have a diagram that more clearly explains how entry into the website actually happens.  Instead of making our homepage a “catch-all” with tons of keywords loaded onto that one page (a common mistake), we have a tightly focused homepage whose subpages lose focus and their specific targeting the closer to the outside that we get.

We now have millions of possible combinations of keywords that interlink like a spider web, lying in wait for a web searcher to put in that highly specific keyword combination… and once they do, they are landed artfully onto the very specific page that matched their search… not some general purpose “inbox” like most homepages.

Focus less on your homepage, and more on your specific micropages…

06-A-Website-is-a-web-Not-a-Funnel-Jared-Nielsen-FUZION.pdf (390.99 kb)

I'm pleased to be speaking to the Miramar group of the Florida Dot Net group at www.FlaDotNet.com.  You can register for this event at the following website:  Click here to register.  I will be discussing how proper search engine capabilities start at the database level using atomic data modeling practices.  The samples of the atomic data model will include how to layer in object inheritance at the SQL Server level, utilizing some new features in SQL Server 2008 including the intrinsic Hierarcy data type and a nice overview of search engine techniques that can benefit from a highly optimized and atomic database.  I hope to see you there!

You can get a head start by reading my blog series on the topic at:

www.NielsenData.com - Atomic Data - Best Business Practices for Product Catalog Data

There are other resources that ascribe to the Atomic Data Modeling concept which you can find at:

Zimbio.com - The Atomic Data Warehouse

Wikipedia.org - Data Warehousing and the use of Atomic Data within the Data Mart

Other announcements of this event include:

• CommunityMegaphone.com
• DeveloperFusion.com
• Upcoming.Yahoo.com
• TechVibes.com

I'm pleased to be speaking to the Miramar group of the Florida Dot Net group at www.FlaDotNet.com.  You can register for this event at the following website:  Click here to register.  I will be discussing how proper search engine capabilities start at the database level using atomic data modeling practices.  The samples of the atomic data model will include how to layer in object inheritance at the SQL Server level, utilizing some new features in SQL Server 2008 including the intrinsic Hierarcy data type and a nice overview of search engine techniques that can benefit from a highly optimized and atomic database.  I hope to see you there!

You can get a head start by reading my blog series on the topic at:

www.NielsenData.com - Atomic Data - Best Business Practices for Product Catalog Data

There are other resources that ascribe to the Atomic Data Modeling concept which you can find at:

Zimbio.com - The Atomic Data Warehouse

Wikipedia.org - Data Warehousing and the use of Atomic Data within the Data Mart

Other announcements of this event include:

• CommunityMegaphone.com
• DeveloperFusion.com
• Upcoming.Yahoo.com
• TechVibes.com

This is the second installment in a series that blends website architecture, data structures, and SEO marketing into a collaborative design pattern continuing from Part 1 - Best Business Practices for Product Catalog Data Structures - Atomic Data 

We've discussed some ways you can create highly discrete or "atomic" data for a product in the first article.  This article will delve into how to evaluate the choices involved in speed versus flexibility.

Any database administrator that works on a high volume, high production website will simply start to quiver uncontrollably however, because there are severe implications for accessing this type of data scattered throughout several tables in a production environment.  Pass him a mug of decaf and let's walk together through how we can tackle the thorny issue of speed related to product catalog data.

We can start with our sample product that we have now mapped into its discrete elements.

This data is fairly granular (or atomic) and is highly reusable within its domain ("Color" categorically means a similar thing to every product that is bound to it).  There are many considerations when it comes to allowing Speed to dictate your design, but I'll list some of the top ones:

• Static Edge Presentation vs. Dynamic Source Presentation
• Precomputation or Data Summarization
• Staged Caching or Static Publishing

Static Edge Presentation 

Static Edge Presentation refers to the concept that data that is requested through web pages goes through many stages.  One model that many people are familiar with is the following:

Generally when the first hit is generated for a distinct URL, such as http://www.domainname.com/?ID=5, the Data Server generates the data needed for the page, the Origin Web Server composes the data into a functional web page, and then the Edge Cache Server distributes that origin page into its "cache" where the unique page sits in "static" for all subsequent hits.  If the page is requested from hundreds of Client PCs after that, only the Edge Cache Server responds to the request (until its cache expires).  If a single Client PC hits refresh over and over again, depending on the Client PC settings, the page is instead served from the Client PC's Browser Cache, which is a local equivalent of server-based edge caching.  This is generally one of the more advanced methods of serving high volume pages in a fast manner (and in a way that the database is impacted the least).  This is the preferred shield which allows your data structures to be a bit more complex (read slow), because at the price of the initial render, the cost per page load is mitigated by the Edge Caching.

Take a page that requires 8 seconds to load.  This is generally considered "too heavy" of a page to be used in production environments.  However, this is only the Origin Page Render cost, meaning it only "costs" this much time for the very first load of that unique page.  If all subsequent page loads only take 0.5 seconds from the Edge Cache for all subsequent hits, then averaged over the numbers of hits, you can quickly see how the page load time continues to approximate the 0.5 seconds load time overall for the page.

Another model is the Dynamic Rendered Page which is far more common to most web developers and online businesses:

This model demonstrates the direct nature of the requests from the Client PC, straight to the Origin Web Server (which gets its data from the Data Server).  In this model, there is generally a one-to-one relationship between the "hit" and the "data request", so the load on the database server is relatively high.  There are tricks you can use to ameliorate this, including Origin Server Caching, SQL Dependency Caching, and other methods, but most implementations use this form of dynamic page delivery.  In this case, data structures that cause delays can severely impact the performance of the application.

 Take a page now, which due to its flatter data model, only costs a 3 second load time.  Because the Edge Cache has been removed from the architecture, your average page load time is going to remain 3 seconds (the page construction happens over and over again for each hit).  While you gain some flexibility by having constantly changing data available on the page, you pay in the overall load on your servers (up to six times more costly in time than an edge cached solution), and you also are forced into a far less flexible data model to compensate for the speed requirements of live rendered pages.

Precomputation

The concept of pre-computation is based on a similar concept as caching.  This means that pretty much anything your database is going to need to "think" about, can in many cases be "pre-thunk."  The art of pre-thinking things before they are needed involves storing what's been thought out and saving it somewhere.  You also have to factor in the speed of retrieving things... some methods of storage are faster than others.

The diagram below (Self Healing Data Retrieval) shows the "layers" that a data request goes through before a page can be rendered.  It's pretty clear that the fastest way to get data to the customer is when the customer asks for a webpage that has been "pre-thunk" already and is waiting in cache at the Edge Cache (Akamai for example).  Here's where the magic happens.  If the page is not available in cache, the Edge cache forwards the request to the Webserver.  The Webserver then can not only generate the page, but it "heals" the Edge Cache by delivering the new page so any subsequent hits to the same page are now "healed" and available on the Edge Cache again.

This type of failover I described above cascades all the way up to the top.  In the examples above, if the Edge Cache fails, the Webserver picks up the slack.  If the Webserver fails, then the Method Farm system checks to see if it has an XML representation of the data in memory (extremely fast).  If the Method Farm doesn't have it in memory, then the Edge Net Storage picks up the slack.  If the Edge Net Storage doesn't have the data, then the Method Farm checks to see if it has it saved in a file on the hard drive (pretty fast).  If the Method Farm doesn't have it written to disk, then the SQL Server attempts to pull a static, pre-generated copy from a static table.  If the static table doesn't have the data, then the SQL server regenerates the data.  In general the failover escalation follows this model:

1. Edge Cache Static Copy
2. Webserver XML
3. Method Farm Memory XML
4. Edge Net Storage XML
5. Method Farm XML from file
6. SQL Server Static Record
7. SQL Server Dynamic Generation from data

In any of these cases, each step is design to "repair" the previous caller that failed.  This ensures that over time, the vast majority of requests are being serviced by the Edge Cache Server and approaches near 100% availability. 

Static Publishing

The last method of high volume, high speed retrieval of web pages that can help reduce load on database systems is the Static Publishing technique.  This means that without waiting for for a user to request a page, the system is designed to "spit out" every single possible page and page combination that could possibly be hit and this entire pile of page data is dumped onto an edge cache somewhere.  There is certainly some value to this, particularly for legacy media archives and other non-dynamic, and non-live page data, but it's use is extremely limited in the e-Commerce arena. 

This highlights to some degree the ways in which network and publishing architecture can drive decisions of data structures in general.  If you choose a more normalized method of data structure, then you need to compensate on the performance side with effective edge caching.  If you choose a more dynamic method of page delivery, then you need to look more toward a flatter, more static form of data model that can deliver the performance that you need.  Many database administrators will tell you that the atomic data model listed above (Sample Product to Property Association) may be too normalized for high volume use, but if the data being accessed is used to serve up pages for an edge cache architecture, the negative is eliminated.

It is important to factor in all of the requirements of your web project before making final data architecture decisions, but it is important to note that deficiencies in one decision (choosing a more normalized data structure) can easily be offset in other ways (choosing edge caching over dynamic page construction).  This may give you more freedom as you make your data structure and architecture choices.

Now that you have evaluated your choices of data models and a highly normalized method is a good architectural choice for your situation, it's prudent to examine the benefits of what the data model will enable you to do.  We will examine some of these benefits in Part 3 - Best Business Practices for Product Catalog Data Structures - Customer Paths.