Shared Vocabulary

Getting Started

Key WordPress terms defined in plain language, so everyone on the team is working from the same understanding.

Core Terms Defined

AWI does not use WordPress Categories or standard Posts. Categories are WordPress's built-in classification system for blog posts—not pages or custom post types. Since AWI's content lives entirely in custom post types (News, Legislation, Resources, etc.), Categories and the standard Posts section are not part of the workflow here. You may see "Category" referenced in WordPress documentation or third-party guides; on this site, ignore it. Everything is organized through Taxonomies and Program Terms instead.

Taxonomy

Custom-built · Attached to one or many custom post types · Has terms, not categories

A taxonomy is a custom classification system built in code. It is attached to whichever content types make sense—one or many. A taxonomy contains terms. Can be hierarchical (parent term > child term) or flat.

On the AWI site, the Programs taxonomy is global. It is attached to every custom post type, standard posts, and pages. This is what allows a single program term like "Farmed Animals" to connect actions, news, Policy Efforts, resources, AWI Quarterly articles, and program pages all at once.

Taxonomy term (correct)  vs.  Taxonomy category (incorrect)—when working with custom taxonomies, always say term.

AWI does not use WordPress Tags. Tags are a flat, non-hierarchical classification built into WordPress core—attached to Posts, which we also don't use. They tend to multiply quickly, create thin archive pages that hurt SEO, and dilute topical focus. You may see "Tags" in the WordPress admin sidebar or in documentation; on this site, ignore them. All classification is handled through Program Terms, which are structured, hierarchical, and maintained by the developer.

Archive Page

Also called: list page, link page

An archive page is a page that lists all posts of a given content type, in order—usually most recent first. It is generated automatically by WordPress based on how the post type is registered. You do not create the archive page manually; WordPress creates it from the posts themselves.

Example: The News archive page lists all published news posts. The AWI Quarterly archive lists all AWI Quarterly issues. You manage what appears on these pages by publishing and unpublishing individual posts—not by editing the archive page directly.

Archive Page with Filters

Also called: filtered archive, search page

An archive page with filters adds an interactive sidebar that lets visitors narrow results by taxonomy terms, keyword, date, or content type—without leaving the page. Results update via AJAX (no page reload).

Example: The Resource Catalogue lets visitors filter by program, resource type, series, and audience simultaneously. The News archive lets visitors filter by program term, news type, and date range. These filters are powered by AWI's custom plugins and the program_terms taxonomy.

Using Program Terms

Program Terms are the only taxonomy you assign as a content editor. The list is fixed—terms are added, renamed, or removed only by the developer. Your job is to assign the right terms to each piece of content, not to manage the list itself.

How to assign terms

  • Every piece of content must have at least one Program Term. Untagged content won't appear in filters, program pages, or related content sections.
  • Use the most specific term that applies. If a child term fits, use that instead of the parent. The parent term inherits coverage automatically—you don't need to assign both.
  • Don't over-assign. If the content genuinely crosses multiple programs, assign multiple terms. But assigning terms loosely dilutes the topical focus and degrades search relevance.
  • Never add, rename, or delete a term in the admin. This is not a style preference—it is a technical constraint. Every Program Term has a slug (a machine-readable ID like farmed-animals) that is hardcoded into queries, archive URLs, filter logic, and template conditions across the site. Renaming a term changes its slug, which silently breaks every query, URL, and filter that references it. Deleting a term removes the relationship from every piece of content assigned to it. These are not reversible with an undo button—they require a developer to diagnose and repair. If you think a term is missing or misnamed, raise it as a discussion. Never touch the term list directly.
  • If you're unsure which term fits, ask. Assigning a wrong term is easier to fix than broken queries across the site.

AWI Program Terms at a glance

  • Terms mirror AWI's program structure—they are not arbitrary labels
  • The same terms are used across every content type: News, Legislation, Resources, Actions, Quarterly, and more
  • Each term has a slug that is referenced throughout the site's queries, URLs, and template logic
  • Parent terms cover the broad program area; child terms represent specific campaigns or sub-topics
  • The list is maintained by the developer; do not add, edit, or delete terms in the WordPress admin

Why the term list stays small

If too many terms are added…
What happens
Terms added for one or two pieces of content
Each term creates an archive page. Search engines see thin pages with almost no content—a duplicate content problem that hurts the whole site's rankings.
Deeply nested or overly granular terms
WordPress slows down in the admin when handling large hierarchical taxonomies. Term queries become expensive and the filter UI becomes unusable.
Content assigned too many terms
The content's topical focus is diluted. Search engines have trouble determining what a page is actually about, reducing ranking potential.
Terms added without a clear purpose
Staff waste time assigning unclear terms. Visitors encounter filter options that return confusing mixed results. The system loses trust.
When in doubt, ask before publishing. A wrong term assignment at scale means updating dozens of content items. A quick question to the developer before you publish costs nothing.