WordPress reserved terms are a set of words, phrases, and variable names that WordPress uses internally for its own functionality — and that should not be reused when registering custom post types, taxonomies, query variables, or URL slugs. Using a reserved term for your own content structures can cause conflicts with WordPress core, leading to broken URLs, broken queries, or unexpected behavior that’s often difficult to diagnose.

These terms exist because WordPress’s query system, permalink structure, and URL parsing all rely on a specific set of identifiers to understand what kind of content is being requested. When a developer introduces a custom post type or taxonomy that shares one of these identifiers, WordPress can become confused about which content to load — a problem that surfaces as 404 errors, infinite redirects, or content that simply refuses to display correctly.

How WordPress Reserved Terms Work

WordPress processes incoming URLs and query strings by looking for known identifiers. Reserved terms appear in three overlapping contexts:

  • Public query variables — Terms used to build URLs and query strings: attachment, author, category, page, post, tag, s, year, month, day, and many others.
  • Internal query variables — Terms used within PHP for database queries: category__in, tag__and, meta_key, post__not_in, and similar.
  • Post type and taxonomy slugs — WordPress’s built-in types (post, page, attachment) and taxonomies (category, post_tag) that must not be re-registered.

A complete list is maintained in the WordPress Codex Reserved Terms documentation. The practical rule: before naming any custom post type or taxonomy, check that name against the reserved list.

Purpose & Benefits

1. Preventing Query Conflicts

WordPress builds database queries dynamically from URL parameters. When a reserved term appears as a slug or query variable in your theme or plugin, WordPress may interpret it as a core parameter rather than your custom one. The result can be queries that return the wrong content or no content at all — a subtle bug that’s hard to trace back to a naming collision.

2. Maintaining Stable URL Structures

WordPress’s permalink system parses URLs to determine what content to display. If your custom post type uses a slug like post or page, WordPress cannot reliably distinguish your content from its built-in content. Using unique, prefixed names ensures the permalink system works as expected and your URLs resolve correctly.

3. Plugin and Theme Compatibility

When building plugins or themes intended for distribution, using reserved terms creates compatibility problems for every site that installs the work. Prefixing custom identifiers with a unique namespace (e.g., mycompany_products instead of products) prevents collisions with other plugins that might register similar post types, and avoids conflicts with future WordPress core updates.

Examples

1. Naming a Custom Post Type Incorrectly

A developer registers a custom post type with the slug post to store press releases. This immediately conflicts with WordPress’s built-in post type. The result: the blog posts section may behave erratically, permalink structures break, and the WordPress admin becomes unreliable. The fix is a unique slug — something like press_release or mco_press_release with a plugin prefix.

2. Reserved Term in a Taxonomy Registration

A theme developer registers a taxonomy with the slug tag for a portfolio post type. Since tag is a reserved term (it’s the URL identifier for WordPress’s built-in post tags), the new taxonomy’s URLs collide with existing tag archive pages. Any URL containing /tag/ now sends ambiguous signals to WordPress’s rewrite system, causing inconsistent behavior.

3. Query Variable Collision in a Plugin

A plugin developer adds a custom query variable named name to filter results on a custom archive page. Since name is a reserved query variable in WordPress (it resolves to a post’s slug), filtering by name produces unintended results — WordPress interprets it as a request for a specific post rather than the plugin’s custom filter. Renaming it to myplugin_name resolves the collision.

Common Mistakes to Avoid

  • Using common English words as slugs without checking the reserved list — Terms like order, type, year, month, post, tag, author, and search are all reserved. Always consult the codex before naming a new post type or taxonomy.
  • Registering post types or taxonomies without prefixes — Unprefixed names like product, event, or service may work on an isolated site but create conflicts when a plugin like WooCommerce (which uses product) is installed. Prefix all custom identifiers with your theme or plugin slug.
  • Assuming “it works now” means it will always work — A reserved term collision may not produce immediate, obvious errors. Problems can emerge when WordPress core updates, when new plugins are added, or when permalink structures change. Test slug names carefully before deploying.
  • Forgetting about WooCommerce and popular plugin reserved terms — WooCommerce adds its own reserved post type slugs: product, shop_order, shop_coupon, and others. Theme frameworks add their own as well. Reserved terms extend beyond WordPress core alone.

Best Practices

1. Always Prefix Custom Identifiers

Use a short, unique prefix for all custom post types, taxonomies, and query variables — typically based on your plugin or theme name. Instead of registering event, register myplugin_event. This is the single most effective way to prevent reserved term conflicts, both with WordPress core and with other plugins installed on the same site.

2. Verify Against the Full Reserved List Before Registering

Before finalizing a custom post type or taxonomy name, check the official WordPress Reserved Terms Codex page. It’s a quick step that prevents significant debugging later. Also check against any other plugins your project depends on — WooCommerce, ACF, and popular page builders all add their own reserved identifiers.

3. Audit Existing Sites for Conflicts

If you’re inheriting or auditing an existing site, it’s worth checking whether any custom post types or taxonomies use reserved terms — particularly if the site has unexplained permalink issues, 404 errors, or content that displays incorrectly. A plugin conflict or slug collision is a common cause of these symptoms in sites that have been extended over time by multiple developers.

Frequently Asked Questions

Why does WordPress have reserved terms?

WordPress’s query and URL system relies on a consistent set of identifiers to parse requests and fetch the correct content from the database. These terms are “reserved” because WordPress has already claimed them for internal use. If a developer uses the same identifier for a custom purpose, WordPress can’t distinguish the two and conflicts arise.

How do I know if a term is reserved?

The most reliable source is the WordPress Codex Reserved Terms page, which lists all query variables and known conflicts. You can also search the WordPress core codebase, or use a helper plugin to output all registered post types, taxonomies, and query variables currently active on a site — comparing that list against your planned name.

What happens if I accidentally use a reserved term?

Results vary depending on which term was used and how. Common symptoms include: 404 errors on custom post type archives, posts from the wrong post type appearing in queries, permalink structures that don’t resolve correctly, or admin screens that behave unexpectedly. The fix is renaming the custom post type or taxonomy and flushing rewrite rules — but catching it early is always easier.

Do reserved terms apply to page slugs in the WordPress editor?

Yes, in part. Certain reserved terms (like author, feed, search, embed) will cause conflicts if used as page slugs, since WordPress uses those URL paths for specific functionality. Creating a page with the slug search will conflict with WordPress’s built-in search functionality.

Are reserved terms the same across all WordPress versions?

The core list stays relatively stable, but new terms can be added as WordPress adds new features. Always check the documentation against the current WordPress version you’re developing for, and include version checks in plugin documentation when relevant.

Related Glossary Terms

How CyberOptik Can Help

As a WordPress-focused agency, we work through custom post type and taxonomy architecture on every project we build. Getting naming conventions right from the start prevents the kind of subtle, hard-to-diagnose conflicts that reserved terms create. Whether you need a custom development project built from scratch or a code audit on an existing site, our developers can help. Get in touch to discuss your project or explore our WordPress development services.