One of the first decisions when building a WordPress site is figuring out where a piece of content belongs — should it be a page or a post? It seems like a minor detail, but the wrong choice creates real structural problems that compound over time.
I see this on a lot of new sites. Blog articles created as pages, core content shoved into posts — and then the navigation gets messy, categories stop making sense, and the whole site becomes harder to manage. It’s the kind of thing that’s easy to fix early and expensive to untangle later.
The Mechanical Difference That Drives Everything Else
Pages are the structural backbone of a site. They’re not dated, they don’t appear in blog archives, and they can’t be organised using categories or tags. According to the WordPress documentation on creating pages, pages are intended for static content that sits outside the normal flow of blog posts — a homepage, About, Contact, a services page, or a landing page for a specific campaign.
Posts are the opposite: date-stamped, organised by categories and tags, and appear in your blog feed and archives. Any content that fits into an ongoing topic area should be a post — tutorials, how-to guides, SEO articles, plugin and tool guides, regular updates.
Getting this wrong doesn’t break anything immediately. The damage is gradual. If blog content ends up on pages, you lose category and tag organisation, your blog archives don’t work properly, and internal linking becomes harder to build systematically. If core pages end up as posts, they get buried in the blog feed, navigation becomes cluttered, and search engines have a harder time understanding what your site is about. This ties directly into how you plan your overall website structure, which affects both usability and SEO.
A Four-Question Framework
1. Does it belong in a category?
If the content fits naturally into a topic category — WordPress Setup, SEO, Website Structure — it’s a post. If it stands alone and doesn’t belong in any category, it’s a page.
2. Will users find it through the menu or through search?
Pages typically appear in your main navigation. Posts are discovered through search engines, category pages, and internal links. If someone would find it by browsing your menu, it’s a page. If they’d find it by searching for a topic or clicking through related content, it’s a post.
3. Does it have a date-sensitive quality?
Posts carry a published date, which signals to readers and search engines when the content was written. Core structural pages like About and Contact don’t need that. If the content is time-stamped by nature, it belongs as a post.
4. Will it expand into related content?
If a topic is likely to generate multiple related articles over time, it should be a post — ideally connected through a shared category. If it stands alone with no planned follow-up content, it’s probably a page.
A Case Where the Decision Wasn’t Obvious
A local accounting firm’s site had a “Tax Deadlines” section — a list of upcoming filing dates and requirements, updated a few times a year as rules changed. On the surface it looked like a page: it wasn’t part of an ongoing blog topic, and the firm wanted it in the main navigation where clients could find it quickly. But running it through the framework flipped that assumption. It had a genuine date-sensitive quality (deadlines change every tax year), it could plausibly expand into related content (a post for each filing category, cross-linked), and search traffic — people searching “tax deadline [year]” — mattered more than menu browsing for bringing in new visitors who weren’t already clients.
The resolution: a page acting as a permanent hub (“Tax Deadlines” in the main menu, linked from the homepage), which itself linked out to individual dated posts for each filing year and category. The page stayed evergreen and structural; the posts underneath it carried the dates, categories, and search-driven traffic. This pattern — a page as anchor, posts as content underneath it — comes up often enough with content that seems to straddle the line that it’s worth trying before forcing a single type to do both jobs.
Practical Tips
Keep your page count small. Most sites need fewer than ten pages. Resist the temptation to turn detailed blog-style content into pages — that content almost always belongs as posts.
Plan your categories before you publish. Categories give posts their organisational structure. Setting them up before you start publishing means every article lands in the right place from the start.
Use pages to anchor posts. Pages work well as hubs. An About page might link to your most important posts. A services page might reference case studies or tutorials.
Match what you’ve already built. If your existing tutorials are posts, keep new tutorials as posts. Consistency across content types matters more than getting each individual decision perfect. If you’re building pages visually, choosing a WordPress page builder covers the main options and what to look for.
Common Mistakes
Using pages for blog content. This is the most common issue on new sites. The result is lost category structure, no blog archive, and content that can’t be organised or scaled properly.
Creating too many pages. When dozens of pages exist that should have been posts, navigation becomes cluttered and the site harder to manage.
Publishing posts without categories. Posts need categories. Without them, your content has no organisational structure, which makes navigation harder for users and less clear for search engines.
Mixing content types inconsistently. Some tutorials as pages, others as posts — this inconsistency weakens the overall structure and makes future organisation much harder.
When It’s Genuinely Borderline
Occasionally a piece of content could reasonably go either way, as the tax-deadlines example above shows. The clearest way to decide: will this topic generate multiple related articles over time? If yes, make it a post and build a category around it. If it’s a one-off piece of structured content that acts as a hub — linking out to posts rather than being one — keep it as a page. And if it needs to do both, consider the page-as-hub-plus-posts-underneath pattern rather than forcing one content type to carry a job it wasn’t built for.
Conclusion
Pages define the structure of your site. Posts build the content. Keep that distinction clear from the beginning and everything — navigation, internal linking, SEO, and content planning — becomes easier to manage as the site grows. If you’re still at the planning stage, the step-by-step guide to building a WordPress website walks through how pages, posts, and site structure all fit together from the ground up.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.