By the way, do you like the clean and short title? I do. Especially when it’s displayed right below this site’s mission statement. Stay tuned.

So what raised a red flag in Dan Sharp’s tweet? He linked to Many SEO Experts Give Wrong Advice Regarding WordPress Permalinks. I’ve condomized this link for a reason. Read on.

Rob from a hosting service based in Portland, Oregon, explains why a 30 days money back guarantee is a good idea, at least when it comes to hosting content rich high traffic WordPress blogs. Full stop. Actually, he claims that some of the most popular search geeks (for example Scott Hendison, Aaron Wall, Joost de Valk, Michael Gray, Matt Cutts, Jordan Kasteler, Vanessa Fox, Adam Audette, Stephan Spencer, Danny Sullivan …) are handing out bad advice on WordPress permalinks. He forgot to mention yours truly, but he’s cursed anyway, so this tiny sin is forgiven easily.

According to Rob, /%postname%/ permalinks shouldn’t be used, because they don’t perform with WordPress. He recommends /%year%/%monthnum%/%postname% and /%post_id%/%postname%/, or crap like that. Of course WordPress tells us that those temporary performance issues with /%postname%/ permalinks are solved:

Starting Permalinks with %postname% is strongly not recommended for performance reasons.   *** Note – this has been changed and is ok to do since ver. 2.0 [Source]

Rob didn’t update his SEO bashing when the bug was “fixed” (in fact, it was just kinda optimized and is not yet really fixed, but at least /%postname%/ permalinks don’t totally jam a blog any more), perhaps because in its current shape his post is nice celeb-bait driving traffic to his hosting service. I don’t care about his reasoning. I’m outing him because he spreads false advice. Even in the first place, before WordPress increased the performance of /%postname%/ permalinks, he took a devious approach.

When a popular CMS develops such a critical bug, the right thing to do is posting a warning like “Don’t update WordPress to version x.xx until the permalink bug that slows down your blog’s performance is fixed”. Accepting such a bug as a feature, and slamming SEO experts for recommendations that were based on a WordPress version that could handle /%postname%/ permalinks without significant performance issues, is malicious. Doing that as a spokesperson of a hosting service is damaging to the company’s reputation. In other words: Bullshit.

Done with this guy. Next.

Apropos bullshit. Reread this rant’s title. Obviously it’s not about a tiny hosting company’s failures. This Weberz hosting dude was about to reveal a real bummer, only he didn’t notice it:

WordPress is fucked up beyond any repair (FUBAR)

In other words: WordPress is utter bullshit. It’s a neat CMS for a personal blog, but it’s architecture is not suitable for professional use. Given its popularity and the number of trafficked blogs utilizing WordPress, that’s seems to be a controversial statement.

Not really. Just because a piece of shit is popular, that doesn’t mean it’s good. Stalin, Hitler, Mao and Pinochet were “popular”, but as dead bodies I like them better. Cobol and RPG/II were popular, but we don’t code in these languages any more, at least not in Web development. WP-Cache and similar plug-ins can prolong the dying of a trafficked blog.

Fortunately, some IT principles survived all paradigms so far, for example normalization, aka good database design. Not that WordPress developers ever considered database design important. Franky, their ERM doesn’t even deserve the predicate “Bullshit” – it’s way worse than any permutation of bullshit I can think of.

If you really want to puke, read discussions about WordPress code, its bug reports, or confusing statements like this one:

For performance reasons, it is not a good idea to start your permalink
structure with the category, tag, author, or postname fields. The
reason is that these are text fields, and using them at the beginning
of your permalink structure it takes more time for WordPress to
distinguish your Post URLs from Page URLs (which always use the text
“page slug” as the URL), and to compensate, WordPress stores a lot of
extra information in its database (so much that sites with lots of
Pages have experienced difficulties). So, it is best to start your
permalink structure with a numeric field, such as the year or post ID.

The latter is interesting, but not understandable without some technical backgrounds. WordPress stores data used to build URIs in different database tables (wp_posts, wp_terms, …). The rules necessary to identify a piece of content (post, page, tag or category page, …) from its URI are stored in a text field in one tuple of the wp_options table. WordPress evals these rules to determine whether an URI points to a post, a page, or whatever, performing one or more database queries per rule.

On a blog with many posts, these “redirect rules” can exceed the limits of a MySQL LARGETEXT attribute, that means they can’t be stored at all. Before this happens, IOW before WordPress crashes with a database error, an HTTP request of a post can result in 2,400 or more database queries just to map its URI to a piece of content. Wow. The next best procedure to slow down page load time is an infinite loop.

Looking at this idiotic software architecture, I’m wondering how much extremely compressed bullshit can be shoved into a developers skull before it explodes out of stupidity.

I don’t know how WordPress increased the performance of /%postname%/ permalinks, and I really can’t be bothered to research it in a conglomerate of unreadable spaghetti code that these CMS clowns produce, mixing up markup with badly abstracted PHP stuff. However, it doesn’t scale, and without significant structural optimization it cannot scale.

What I can tell is that without a database table that stores URIs (URI as a unique index) with references (uri_id as foreign key in all related tables or so) to various entities like posts/pages/categories/tags and so on, preferably iplementing historizing to handle changes of the permalink settings with 301 redirects, WordPress cannot solve the performance problem.

CMS developers should know that “universal” in URI doesn’t mean “anything I can grab from various attributes stored in a couple of databse tables without properly implemented functionality that guarantees that each URI is unique on the Internet”. “URI” is an object that as an attribute of anything that counts as “piece of content” maintains its unique address, across the Web.

If you aim at high traffic, WordPress is not for you. Since SEO is about generating high volumes of traffic, WordPress is not for your clients.

The reaction by Michael Gray Is WordPress Good or Bad for SEO? might as well answer a few questions from the comments.

Last time I looked, search engines evaluated links when drawing site hierarchies and link graphs. They give a dead rat’s ass if your fucking URIs match utterly meaningless file system structures. URIs are totally independent of OS restrictions, hierarchies, and brain farts as well.

So why do so many “SEOs” out there still advise their clients to maintain URIs within a (pseudo) file system hierarchy? Because someone replaced their brain with a pile of bullshit. Or pseudo-PageRank. Or both. Or other disgusting crap.

Well deserved insults left aside – here comes the academic explanation. It’s all Google’s fault. Back in the good old days when Google was dancing monthly, they had a faulty algo in their toolbar that kinda “guessed” PageRank, partly based on directory structures. It displayed a green pixels width (of upper directory) minus one or two pixels for URIs without an entry in the propagated toolbar PageRank database.

If an indexed page example.com/holy/index.html showed 4 green pixels, a not yet indexed page like example.com/holy/crap.html sometimes showed 3 green pixels.

Of course PageRank isn’t measured in green pixels. Savvy SEOs knew that toolbar PageRank is for entertainment purposes only, and that guessed toolbar PageRank means less than nothing with regard to free search engine traffic. Unfortunately, not all webmasters and SEOs are savvy. Actually, most aren’t, thanks to stultifying webmaster hangouts and the SEO blogosphere.

Many clueless SEO clowns chasing toolbar PageRank begun to serve all their crap from the root directory. Until the next SEO myth came out. Well, breadcrumb navigation is a great thing to do, if it makes sense, but it doesn’t boost PageRank on “directory level” via underlying URI structures (mimicking a static file system). Not in the root, not in deeper levels. Never. PageRank is solely influenced by links and their attributes.

Changing URI structures from root-only to equally keyword stuffed directory structures resulted in useless 301 orgies, making crawling and indexing more complex for search engines. In fact, it created redirect chains like example.com/products/sku (initial version) to example.com/sku (root-only version) to example.com/category/subcategory/justanotheruselesslevel/sku.

Two more revamps (plus server name canonicalization), and search engines won’t index any product page, because five redirects in a row is the maximum. There’s no maximum when it comes to SEO myths, so probably most over-SEO’ed pages will drop out of all search indexes soon.

I love idiocy. Really, I do love it. I’m going to launch just another SEO myth like “replace slashes with backslashes because Google fell in love with IIS” and that’s four. Next up is “replace \.htm|\.php|\.html with \.asp|\.aspx because Bing gives those script name extensions more weight” and that’s five. The day after tomorrow I’ll dominate the InterWebs. Aaaahhhrrrggg…

So why is the totally flawed concept of hierachical URIs, as in file systems, so popular? Because meaningful URIs make sense for (bookmarking) users, and increase SERP CTRs. Not that a visitor cares about the hierarchies a webmaster considers logical. The opposite is true.

E.g. example.com/widgets/green/xxl is very much webmaster friendly, but meaningless to users. A visitor would appreciate example.com/green-widgets/ and prices for all sizes (XS to XXL) on this page (even better would be example.com/widgets/ where the punter can chose color as well as size). A search for [green widgets in XXL] or so delivers the desired sales pitch just as [green widgsts] (sic!) without a size.

In fact, on very few sites any hierarchy in URIs makes sense at all. If there’s no hierarchy from a user’s (current) point of view, example.com/sku (or example.com/unique-keyword-phrase or example.com/buy/unique-keyword-phrase|sku) is the best choice (for a good looking and meaningful URI). That doesn’t mean you should drop hierarchical breadcrumbs. It means that URIs have nothing to do with the structure of your vendor’s data feed, and that breadcrumbs aren’t static.

In real live, hierarchies just don’t work. Most users don’t browse Yahoo’s directory or the ODP, they perform a search. This sort of categorizing is flawed by design, because the result is always subjective and therefore not generic enough to be useful for everyone. Don’t say “but Yahoo did it too, so it can’t be that wrong”. Trust me, it’s outdated bullshit, a relict of the Internet’s early Jurassic. Just because my ancessors buried their dead bodies in trees, that doesn’t mean that I can’t have a funeral at sea.

A node (Web page) can appear at many coordinates in a webbed structure (Web site), and each coordinate can be expressed as another navigation path (breadcrumb) leading to this node. That makes the breadcrumbs transient, and you must not use transient attributes or behavior as (parts of) persistent identifiers, like URIs.

Rest assured Google can (at least will) handle dynamic breadcrumbs without losing the node’s actual context (with regard to search query relevance), so ditching on your static breadcrumb components in URIs will neither lower SERP CTRs nor uglify SERP displays. You’ll get a breadcrumb’ed SERP display even for ugly URIs like example.com/p?id=Hj8TSc&ctx=k0Oh5Ew, because the breadcrumbs are gathered from links, not from path components of URIs.

In other words: your information architecture should be based on estimated (even better: tested!) user behavior, not on your product portfolio or technical indicators. Make short and meaningful URIs for users. Provide short click-paths to all of your contents. Interlink the hell out of your page portfolio. Link for the sake of your sales and easy navigation as well, not hierarchical following alien structures like category/vendor/product/color/size.

If it makes sense, search engines will follow suit. They don’t care much about path components of URIs. A page linked from the root index page or a powerful hub will rank well regardless whether it’s URI is example.com/sku or example.com/products/sku. It’s liked by users when its URI is example.com/green-widget.

You don’t even need to provide a consistent URI pattern. Having a ton of ancient example.com/sku URIs plus fewer example.com/meaningful-string URIs for newer products as well is fine with the engines, and fine with your users. As long as your linkage is user friendly.

Think! Be creative. Don’t fall for ancient sagas.