The Finer Points of “Posts” and “Pages” in a WordPress Context

One of the most complicated things for a relative-beginner in WordPress use and development is that WordPress has some specific and overlapping vocabulary. Some things mean multiple different and kind-of-conflicting things. The two most common offenders of this for WordPress folks are “posts” and “pages.” In this article we’ll break down the possible ways that people may use either of those words in terms of a WordPress site, and what they mean.

A Web Page is an HTML Document

What you may or may not know is that ALL “web pages” are simply HTML documents being served to your web browser.

The first and in some ways the most fundamental way people use the word “page” is to refer to a web page. In the sense that “I’ve got Safari open and I’m looking at your page.” In this case, this means nothing WordPress-specific, we’re just using it as a very general term for an HTML (HyperText Markup Language) document. What you may or may not know is that ALL “web pages” are simply HTML documents being served to your web browser, which it then interprets and renders, just as Microsoft Word or Adobe Photoshop can read and display that type of document. Which one is displayed depends on the specific URL — or web address, like http://www.example.com/page — visited.

To bring this idea into a WordPress context, WordPress is a what’s known as a “content management system” (CMS for short) which is a shorthand way to say “a system that makes it easy to generate HTML documents for arbitrary content.” A WordPress post, a product in a WordPress e-commerce system, etc are all displayed to visitors through a range of HTML documents that WordPress — working in concert with your theme, and probably a few different plugins — puts together. This means that normal people who aren’t necessarily familiar with the idea of building an HTML document themselves can make information available on the internet with relative ease.

As a CMS, WordPress Supports Many Content Types

Specifically, WordPress comes built-in with two content-types, “Posts” and “Pages.”

So, one way WordPress users and developers may use “pages” is to mean HTML documents, or “web pages,” which are essentially the public output of content management systems. Then, there are various content types that WordPress may facilitate the management of. Specifically, WordPress comes built-in with two content-types, “Posts” and “Pages.” (Technically, there are also: media attachment, revision, and nav_menu_item; but that’s all beside the point.) A literal infinite assortment of other types can be made, but we’ll not get ahead of ourselves.

WordPress’s “Post” content type, which is the one most people think of when they think of WordPress, is for “blog posts.” This is a content type that is meant to be part of a stream of reverse-chronologically-sorted (newest-ones-first) entries. Generating and publishing blog sites was WordPress’s first big source of popularity. “Posts” are the content-type for which your WordPress site will automatically have tags and categories. It is used, depending on the context, as the most important and only content-type on a website, or a rarely-used corner of something like an e-commerce site.

WordPress’s “Page” content type, is kind of the opposite of the “Post” content type. That is, where “Posts” are meant to kind of blend into a stream, each page is meant to stand on its own, and be somewhat timeless. Originally, they were mostly used to house things like an “About” page on a WordPress blog, but today they serve a huge array of purposes.

Plugins (and themes, though they shouldn’t…) can add new content types to a site.

Finally, plugins (and themes, though they shouldn’t…) can add new content types to a site. Maybe these are “forms,” or e-commerce “products,” or “articles,” or “store locations.” They can be pretty much anything, the limits are just plugins you have access to or can write for yourself. We can think of content types as just “data bags” for all types of stuff. The ability to create arbitrary content-types to suit your needs is what makes WordPress a true content management system. But that leads to the other way that “posts” gets used…

Internally, It’s Kind of All “Posts”

What we’ve shielded you from so far in this story, because average users don’t really need to know it, is that internally for developers WordPress uses the word “post” for lots of things that are really just pieces of content belonging to one of those types on the WordPress site. Because WordPress started as blog software (and cares a lot about keeping older things working), a lot of internal functions and “APIs” (groups of functions, basically) that are well-established use the word “post” when they mean “arbitrary content type.”

A lot of internal functions and APIs that are well-established use the word “post” when they mean “arbitrary content type.”

This means that in the database, where WordPress stores content, all the pieces of content are in a “database table” — basically a structured subset — called wp_posts (or similar). Similarly, when you create a new content type, WordPress developers know that you’re actually registering a new “custom post type” using the register_post_type() function. (Because of this, what we’ve called “content types” so far are often called “CPTs” or “custom post types.”)

Similarly, when you attach additional metadata to any piece of content, you’ll hear that data regularly referred to as “postmeta.” This is because it is most frequently fetched with a function called get_post_meta(), and is stored in a database table called wp_postmeta.

I could elaborate numerous other different but similar examples, but I think you’re understanding the point: when a function or technical underpinning like the database says post, it probably means data from any content type. It’s a bit of a hassle to know and remember this, but it’s a little speed bump that enables WordPress’s world-class ability to continue to be updated and enhanced without breaking working stuff.

Confuse Posts and Pages No More

So, when someone says “post” in a WordPress context, they’re likely referring to one of two things:

1. The “Post” content type, which could also be thought of as “blog entries.”
2. An individual content entity (“a post”) that belongs to one of the numerous content types that WordPress supports, like “Posts,” “Pages,” “Products,” etc.

Similarly, when we talk about a “WordPress page,” we may either mean:

1. The “Page” content type, which is for discrete one-off content entries which shouldn’t be thought of as part of a time-based stream.
2. Any of the various forms of HTML documents or “web pages” that WordPress is capable of creating and outputting to visitors, for any of its massive number of content types, including “Posts.”

It’s a bit weird that both of these terms have two very important but quite distinct meanings. Part of this is a direct result of WordPress’s deep commitment to backwards-compatibility — in the case of everything secretly being a post — and part of it’s just that the web is used by lots of people with lots of different ways of talking about it.

WordPress is our favorite CMS because it has such a broad and powerful ecosystem around it. This ambiguity is just a small speed bump on the road to being able to really master WordPress, the most powerful and used CMS on the internet. It’s worth learning the few warts because the power and possibility of WordPress is so vast. Happy hacking!