MYTH: A page two directories deep is going to be less optimized than a page in the root.
FACT: What matters is where you, and others, link to. If you have a page three directories deep with lots of high-quality internal and external links it will outperform a page in your root with few internal and external links for the same keywords, all other things being equal.
I’ve heard a lot of people talking about flattening site architecture, which is generally a good thing. Like all good things in SEO, people are quick to take it over the edge and turn it into something bad for their clients. There are many reasons why you would not want to put everything in the root folder, especially when dealing with product pages on an eCommerce website. Here are the top three that come to mind…
Why Putting Products in the Root Doesn’t Make Sense:
1. It Makes Diagnosing Issues More Difficult
This is a great query that can provide you with a wealth of information IF your URLs are structured correctly: site:yourdomain.com inurl:product. If you have more product URLs indexed than you have products on your site, this would indicate a possible duplicate content problem via non-canonical URLs, such as those with view parameters or variants. Conversely, if you have fewer product URLs indexed than you have products on your site it could indicate a crawlability problem or worse. Now imagine trying to get that simple piece of information without having anything to “latch onto” that identifies a URL as belonging to a product.
2. It Makes Redirects More Difficult
Let’s use an example to illustrate this point. Imagine you are moving to a new eCommerce system that requires all products to go into a folder/directory called “items”. It could be called product, products, services… but we’ll use “items” for the sake of example.
If you were starting with a flat site architecture like the one diagrammed on the right side of Rand’s whiteboard (https://www.seomoz.org/blog/whiteboard-friday-flat-site-architecture) in 2009 you may be working with something like this:
In the above situation, how do I tell the server to automatically redirect just the product pages without specifically asking for each of them to be redirected separately? I suppose you could append something to the filename, as in: AwesomeStore.com/productname1-product but, now you are diluting another SEO factor, the name of your product.
On the other hand, if you had organized your site using category and product directories, it might look like this:
In the above situation, I can tell the server to redirect all URLs in the “products” directory to the “items” directory without changing the product name or any other part of the URL. Although I’m no expert at writing regular expressions, you could probably do this with a single line of code like:
RewriteRule ^products(.*)$ https://www.awesomestore.com/items$1 [L,R=301]
3. You Lose Some Breadcrumb Control:
While not the end of the world, it is nice for people to see something like this in the SERPs: Awesome Stuff Store -> Purple Stuff -> Purple Doohickey
You can accomplish this without actually having categories in the product page URL by assigning a default category on the back-end and using that in the breadcrumb microformatting markup, like that found on Schema.org. Google wants to see that the breadcrumb you provide them in the markup matches the navigational path their crawlers take on your site so, while not impossible, it becomes more difficult to get the full breadcrumb path to show if your categories and products live in the same directory.
If you ask 100 developers which they prefer, I’d bet 99 of them would choose to put products in their own directory for reasons stated above, and because developers tend to be very logical people. When we take the taxonomy concept typically used in biology discussions and apply it to information architecture, it allows both humans and machines to make more sense out of the way we categorize things on a website, such as articles or products. To have a conceptual taxonomy for humans (e.g. Sony Bravia belongs in the Television subcategory, under the main Electronics category, under the Products page-type) without any system of categorization for machines is, in my opinion, not the best strategy. It tends to make the machine work harder to figure out the taxonomy on their own. The last thing you want to do is make Googlebot work hard to understand your site. And to think you’re going to fool Google into assuming your product detail pages, which are only linked to from your category pages, are somehow at the same “level” of importance as your main categories just because they’re in the same directory is probably a little naive. If that is your goal, you would do a much better job of sending that message with internal and external links.
But of course we don’t put all of our products into the main navigation, which tells a search engine something about the structure of our site, regardless of whether our products are in the root or not. However, you can certainly put “featured” or “popular” products in the navigation to reduce the clicks necessary to reach those products and to send more page-rank their way, not to mention increase sales.
The architecture of your site is one more tool in your arsenal. It is your ability to guide visitors and crawlers around in ways that make sense to them and benefits your bottom line. Even if there was a small SEO benefit to putting everything in the root, it wouldn’t be worth the trouble in the long run for reasons stated above.
Great advice, directories are extemely important, in fact it helps with robots.txt or mass removing pages from google too.
but as you say best of all it helps with queries like
one i have been using since 2004!
You should also avoid putting categories into product page URLs because sometimes products change categories, or exist in two or more categories simultaneously. Also, while I do like to put products into their own directory, that doesn’t mean I think it’s a good idea to add on superfluous directories either for keyword stuffing or because developers want to avoid the work of doing mod rewrites to fix the issue. But perhaps that’s another blog post for another time.