Development
WordPress Ships a Blog, Not a CMS
Out of the box, WordPress is a blog
Out of the box, WordPress gives you posts, pages, categories, and tags. That is a blog. A competent one — with a mature editor, a hardened security posture, a plugin ecosystem two decades deep — but a blog. If your institution publishes clinical services, degree programs, legislative districts, or research initiatives, those are not posts. They are entities with properties, relationships, and editorial rules that WordPress, by default, has no concept of.
The gap matters because most WordPress projects never cross it. A developer installs WordPress, drops a theme, and builds out pages with nested blocks or hardcoded fields. The site launches. Two years later, the client needs all services surfaced by region, or program descriptions reused across three templates, or a new location added without a developer. None of that works when content is buried in page bodies, written once for one context, and never modeled for reuse.
The theme controls how things look. The content model controls what things are.
The real work is defining the entities
A content model starts with register_post_type — one call per entity type, with its own labels, capabilities, and REST visibility. Programs, locations, providers, events: each gets its own type, not a category slapped onto posts. Then register_taxonomy binds the classification axes: specialty, campus, audience, status. Relationships between types — a program linked to its faculty, a location linked to its services — get handled through ACF relationship or post-object fields, stored in acf-json under version control so the schema travels with the codebase.
Field groups are the contract. Every field group defines what an editor can fill in and what a template can consume. Name, description, audience, accreditation body, application deadline: these live as discrete fields, not inside a paragraph an editor typed in 2019. That discreteness is what makes a thousand-page site operable without a developer in the room. The template is a view over structured data; it doesn't care which year the editor filled in the form.
The shape of your content is the infrastructure
We have built content models for institutions that publish at a scale where the wrong model costs real money — twenty-one years of that work have a consistent finding: the projects that age badly are not the ones with outdated themes. They are the ones where the content was never given a shape. Every redesign begins with an archaeology dig through page bodies, trying to reverse-engineer what someone meant to publish. The model that existed was implicit, undocumented, and locked inside the presentation layer.
A well-modeled site is one where a new content type can be added in an afternoon: define the post type, write the field group, wire the template, deploy. No database migration scripts, no page-builder workarounds, no legacy data to untangle. That afternoon is what Keystone and Beacon are built around — a content architecture that an institution can actually own, extend, and hand to the next team without a translator.
WordPress becomes a CMS the moment you decide what your content is and build the model that says so. That decision happens before the theme, before the page templates, before the editor training. The institutions that run clean sites ten years later made it early. The ones calling for a redesign made it late, or never made it at all.