[wp-hackers] Permalink Structure - Performance vs. SEO

[Mike Schinkel]

On Jun 15, 2011, at 12:27 AM, Lynne Pope wrote:
> I'd agree *IF* the site is a date-based blog.  If, however, it is using
> WordPress as a content management system then there is nothing
> wrong with the content strategy. 

Those are arbitrary distinctions.  A post is for date-based content on a site; a blog, a news item, an update, etc.  Date-based content is still content, and using it as a CMS is used to mean so many different things it doesn't have a strong meaning, especially not for use the define use-cases in a debate.

> Consider a book published in 2005.

Create a "Book" content type. If there are many books like at a publisher, include the year in the URL.  If a single book for an author's blog, maybe not.

> The author could keep adding addendums and errata to keep the material updated 

Create an "Addendum and Errata" content type, and include the year and month in the URL. Link each from the book content type.  Reference each addendum and errata in a blog post, or just use blog posts for addendum and errata.

> but sooner or later that author will release a new book.

Not sure how this latter part is germane to the discussion?

> The same is true on sites that provide technical or legal information.
> Small changes occur regularly. The site owner can choose to write a
> new post, copying the majority of the earlier advice and including the
> change. Or they could update the original post to show deletions of
> outdated information and insertions of new. The post may be 5 years
> old and completely up-to-date with latest developments.

In all those cases, updating time-based posts is a convenience for the author but not good content strategy, nor a good site architecture nor a good user experience.  I posit that in WordPress time-based events should be documented in time-based post types with time-based URLs. Persistent topics (like a Wikipedia entry) should be maintained and then linked from-and-to the time-based posts.  

I've studied this problem for many more years than WordPress has existed (starting in 1987 with database design and 1994 with web architecture) and I've yet to find a pervasive example that violates these principles.  I'm not saying a use-case doesn't exist, I'm only saying that I've never recognized one.


> All of this depends on how people are using WordPress. The assumption that
> people only blog is fragile.

You mentioned "people only blog" assumption in reply to me, I did not mention that.  I'm very unlikely to ever make that assumption. I actually err on the opposite end of the spectrum since probably 90+% of my company's revenue is from clients that are using WordPress to build business sites that are not primarily blogs.

> Dates are relevant to blogs.

Dates are also relevant to any content that is time-based such as press releases, news stories, events, product promotions, newsletters, investor reports, and the list goes on (I just used http://www.oracle.com/ to give me inspiration for things that are date-based but not blogs. I doubt Oracle's main website would be considered "a blog.")

> Publication dates AND last-modified dates are important to all other publications but not
> necessarily wise to have in the URL.

And those types of content should either be post_type='page' or a custom post type.  Or maybe I'm wrong?  I'd love to hear why that type of content would be better stored in post_type='post' that isn't "I'm not technical enough to figure out how to make it work."

-Mike

P.S.

> Anyway, I've said my bit. I'll be quiet now and wait till the core can
> handle %postname% without impacting performance as it does now ;)

Ironically I've got an extension that can do exactly that. It's in pre-alpha test, but AFAIK it works except for maybe a few edge cases. Anyone interested in testing please create a free bitbucket.org account and email me directly with your bitbucket screen name.