How the Site Works
A plain-language guide to the site's design philosophy, content structure, and why things work the way they do.
On This Page
→ Structured Content, Not Free-Form Pages → Program Terms: How Everything Connects → The Relational Web: One Tag, Many Places → Why the Theme Controls the Look → Why We Don't Customize with HTML → Why We Don't Add Pages Just Anywhere → The Short VersionStructured Content, Not Free-Form Pages
The old AWI site was largely built from individual pages—each one a blank canvas where editors could paste text, add images, and drop in custom HTML to make things look the way they wanted. This gave a lot of flexibility in the moment, but created serious problems over time: inconsistent formatting, content that broke during updates, pages that looked nothing like each other, and a site that was nearly impossible to maintain at scale.
The new site is built differently. Instead of blank pages, most content lives in content types—structured templates designed for a specific kind of content. There is a content type for news, one for Policy Efforts, one for resources, one for actions, one for AWI Quarterly articles, and so on. Each content type has defined fields: a title, a body, an image, a release date, program terms, and so on.
Think of content types like forms with specific fields. A press release form asks for a title, body, release date, image, and program term. A Policy Efforts page asks for content, citations, program term, and whether it's a law. You fill in the fields, and the site handles how it looks.
Why does this matter?
Because the site can do things with structured content that it can't do with free-form pages. It can automatically pull the three most recent farm animal news items onto the Farmed Animals program page. It can list all active Policy Efforts tagged under Marine Terrestrial Wildlife. It can build a filterable archive of AWI Quarterly articles by program. None of that is possible if content is just text dropped onto arbitrary pages.
Program Terms: How Everything Connects
The most important organizing concept in the site is a taxonomy called Program Terms. A taxonomy is simply a system of labels—like folders, but smarter, because one piece of content can belong to multiple folders at once.
Program Terms mirror AWI's program areas. They are hierarchical—meaning they have parent terms and child terms:
Example Program Term hierarchy
- Farmed Animals (parent, AKA Program Term)
- Animals on Factory Farms (child, AKA Campaign Term)
- Marine Terrestrial Wildlife (parent, AKA Program Term)
- Whaling (child, AKA Campaign Term)
- Terrestrial Terrestrial Wildlife (parent)
- Wild Horses & Burros (child, AKA Campaign Term)
Every piece of content on the site—press releases, Policy Efforts pages, AWI Quarterly articles, resources, action alerts, WYCD items—gets tagged with the relevant program term. This tag is the connective tissue of the entire site.
Program Terms are applied to 13 different content types and appear in every filter, search, and related content section on the site. When you assign a program term to a piece of content, you are not just organizing it—you are plugging it into every part of the site that references that program.
The Relational Web: One Tag, Many Places
This is the part that takes the most explaining, but it's also the most powerful. The site uses a relational model—which means content is not just filed in one place. One piece of content, tagged correctly, appears in many places automatically.
Here is a concrete example. A staff member publishes a press release about wild horse roundups and tags it with Equines > Wild Horses & Burros. That single tag causes the press release to automatically appear in:
- The Equines program landing page—in the "recent news" section
- The Equines program landing page, the Wild Horses & Burros campaign detail page—in the latest news and articles slider
- The News archive—filterable by "Equines"
- The Sitewide content search—findable when filtering by Equines
- Any AWI Quarterly article also tagged Equines > Wild Horses & Burros—in the "related news" section alongside it
- Any Policy Efforts page tagged Equines > Wild Horses & Burros—in the related press section
No one manually put the press release in each of those places. The tag did all of it. This is what "relational" means: the database understands the relationship between the press release and everything else tagged Terrestrial Wildlife, and surfaces that content automatically wherever it's relevant.
The same logic applies across every content type. A new action alert tagged Farmed Animals shows up on the Take Action page, the Farmed Animals program page, and every relevant campaign page. An AWI Quarterly article tagged Marine Terrestrial Wildlife appears in the related reading section of marine Policy Efforts pages. A funding opportunity tagged Terrestrial Wildlife surfaces in the Terrestrial Wildlife section of the opportunities page.
Why the Theme Controls the Look
On the old site, editors had significant control over visual presentation using inline HTML and CSS. You could change font sizes, add colors, apply bold formatting to things that weren't really headings, paste in HTML tables, and build one-off layouts for individual pages. This felt empowering, but created a cascade of problems:
| What editors did | What happened over time |
|---|---|
| Made text bold and large to look like a heading | Screen readers skipped it. Search engines ignored it. Different pages had different visual "headings" that weren't semantically headings. |
| Typed out bullet lists with dashes or asterisks | Visually looked like a list but wasn't one. Screen readers read it as plain text. Search engines didn't see structure. |
| Pasted HTML tables for layout | Broke on mobile. Inaccessible. Font, spacing, and color didn't match anything else on the site. |
| Used colored text to highlight information | Inconsistent across pages. Inaccessible for color-blind users. Failed contrast requirements. |
| Added inline styles to "fix" spacing | Broke when the theme updated. Created overrides that conflicted with design changes later. |
The new site puts the theme in control of all visual presentation. When you add a heading, the theme applies the correct font, size, weight, and spacing—every time, on every page, consistently. When you upload an image with a photo credit, the credit appears in the correct style automatically. When you add a callout block, it looks like every other callout on the site.
This is not a limitation—it is what makes the site look professional and coherent at scale. A site with 5,000 pages managed by dozens of people, across years, needs a design system that enforces consistency. The theme is that system.
Why We Don't Customize with HTML
The old site accumulated a significant amount of custom HTML—hand-coded styling, inline CSS, pasted-in code snippets, embedded iframes, and layout hacks applied directly to page content. This created a site that was:
- Fragile—custom HTML breaks when the theme or WordPress updates. Pages that looked fine could become unreadable after a routine software update.
- Inaccessible—custom styling bypasses the accessibility checks built into the theme's design system. Inline styles can create low-contrast text, non-navigable structures, and content that screen readers cannot parse.
- Unmaintainable—when custom HTML spreads across hundreds of pages, there is no way to make a sitewide change. You have to find and edit every instance by hand.
- Inconsistent—each hand-coded page looks slightly different. Over time, the site stopped looking like one coherent product and started looking like a collection of individual experiments.
- Invisible to search engines—HTML formatting does not make content more findable. Proper semantic structure (headings, lists, paragraphs) does. Custom HTML often undermined the structure Google and AI tools use to understand the page.
The new site has custom blocks for exactly the situations where you need something beyond a paragraph: quotes, accordions, image-with-credit, data tables, sliders, CTAs, and more. If you find yourself thinking "I need to add some custom code to make this look right," that is a signal to stop and ask the developer whether a block already exists for it—or whether one should be built.
Why We Don't Add Pages Just Anywhere
WordPress makes it easy to create a page. Too easy, in fact. On the old site, this led to hundreds of pages created without clear purpose, filed in the wrong place in the hierarchy, using inconsistent naming, with no connection to the site's taxonomy system. The result was a site that search engines couldn't map clearly and staff couldn't navigate reliably.
On the new site, most content should live in the correct content type, not as a standalone page. Before creating a new page, the first question is: does a content type already exist for this?
Does your content have a home already?
| If you want to add… | Use this, not a new page |
|---|---|
| A press release or statement | News content type |
| A bill or policy AWI supports | Policy Efforts content type |
| A grant or funding opportunity | Funding Opportunities content type |
| A report, book, or brochure | Resources content type |
| A call to action for visitors | Actions content type (with CongressPlus) |
| An AWI Quarterly magazine article | AWI AWI Quarterly content type |
| A job posting | Jobs content type |
Pages—as in, the "Pages" section of WordPress—are reserved for structural parts of the site that don't fit a content type: the About Us page, the Contact page, the Home page, and other fixed destinations. Program pages use the Program content type, not the Pages section.
Adding content in the wrong place doesn't just cause organizational problems. It means the content won't be picked up by the taxonomy system, won't appear in the correct archives or search filters, and won't have the right template applied. A press release added as a generic WordPress page instead of a News post will never appear on the program page, never be filterable by news type, and never get the correct publication date treatment.
The Short Version
Every decision in how this site was built comes back to a few core principles:
Structure over flexibility
Structured content types let the site do work automatically—surfacing related content, building archives, populating search filters—that would otherwise require constant manual updates.
Tags connect everything
Program Terms are not just labels—they are the relational system that links every piece of content across every program area. Tag something correctly once, and it appears everywhere it belongs.
The theme owns the style
Consistent visual design across thousands of pages is only possible when the theme—not individual editors—controls how things look. This is what makes AWI's site look like one site, not a collection of individual pages.
Consistency builds visitor trust
When every page uses the same typography, spacing, and color, users can focus on the content instead of reorienting themselves every time they navigate. Predictable layouts reduce cognitive load—visitors know where to find headings, where links will appear, and what a button looks like before they even read the label. The moment a page looks "off" due to an inline style override or a pasted layout, it signals to the visitor that something is wrong.
Maintainability is a feature
Every shortcut taken in content entry—a custom color, a pasted HTML table, a page added in the wrong section—becomes technical debt that someone has to clean up later. The rules here are not arbitrary; they are what allows the site to stay fast, accessible, and up-to-date as AWI grows.
Accessibility drives search visibility
Search engines crawl pages the same way screen readers do—by reading semantic HTML, not visual appearance. Proper heading structure tells Google what a page is about. Alt text gives search engines indexable content they can't see. Clean markup loads faster and signals a well-maintained site, which Google rewards in rankings. Content buried in inaccessible structures—layout tables, fake headings, missing alt text—is content search engines skip or devalue. Accessible content isn't a courtesy feature; it's what makes AWI's work findable.