Pods

Pods is a free WordPress content-modeling framework for sites that need custom post types, taxonomies, settings pages, relationships, and custom fields in one system. It goes beyond adding metadata to posts by letting you design the content structure itself.

Quick take

Pods fits builders and developers who want a free, integrated toolkit for structured content. It can create and extend content types, add custom fields, connect records through relationships, and expose content through templates, blocks, shortcodes, and PHP. It is broader than a field-only plugin, so the trade-off is that migrations need to account for post types, taxonomies, relationships, templates, and field data together.

What Pods covers

Pods can create custom post types and taxonomies, extend built-in WordPress objects, create settings pages, and add custom fields. It also supports Advanced Content Types stored in their own custom tables, which changes the data model compared with ordinary post meta.

Field support includes text, numbers, dates, media, relationships, repeatable fields, layout elements, and conditional display. Relationship fields are a major part of the product because they can connect posts, users, taxonomies, media, and other objects.

Where Pods differs from ACF

ACF is commonly used as a field layer added to an existing WordPress content model. Pods can replace more of that surrounding structure by creating the content types, taxonomies, relationships, settings screens, and fields together. Pods also provides its own templates, shortcodes, blocks, and front-end content forms.

This broader scope can reduce the need for a separate custom-post-type plugin, but it also means a complex Pods setup can become more framework-like than an ACF field group. Teams moving between the two should map data storage and template dependencies before switching.

Relationships and data modeling

Pods is especially useful when custom fields are only one part of the problem. Directory, property, staff, course, and editorial projects often need records connected to other records. Pods relationships can connect posts, users, taxonomies, media, and other objects rather than storing every reference as an isolated value.

During migration, relationship fields need more than matching labels. Preserve the linked object type, whether the relationship is single or multiple, and the queries or templates that consume those relationships.

Displaying structured content

Pods can expose structured content through blocks, shortcodes, Pods Templates, widgets, PHP, and front-end forms. Before switching from ACF, inventory every place custom data is rendered: theme templates, block templates, page-builder dynamic tags, REST endpoints, shortcodes, custom queries, schema markup, and third-party integrations.

A migration is complete only when those consumers still receive the expected values. Test text, number, date, media, repeatable, and relationship fields separately because each can fail differently.

Pricing and licensing

Pricing checked: September 23, 2026. Pods is free and open source. Its core custom fields, content types, relationships, settings pages, templates, blocks, shortcodes, and front-end form tools do not require a paid plugin license.

Migration considerations

Do not treat a custom-fields migration as a simple label change. Record field names, field keys, post types, taxonomies, relationship behavior, repeatable data, template calls, shortcodes, and REST/API consumers. Advanced Content Types deserve extra attention because their data can live outside normal WordPress post meta tables.

When replacing ACF, test the front end and any page-builder dynamic-data connections after importing data. Existing PHP that calls ACF functions such as get_field() will also need to be rewritten or kept behind a compatibility layer.

Who Pods fits

Pods is relevant for directory sites, editorial databases, internal tools, listings, portfolios, and other projects where the content model matters as much as the fields themselves. A developer who only needs a small group of custom fields may find its broader framework unnecessary, while a project with multiple linked content types can benefit from keeping the structure in one system.

Frequently Asked Questions

Data-model planning and handoff

Pods can grow from a simple field editor into the data layer for directories, catalogs, editorial systems, and relationship-heavy sites. Before expanding a Pods build, document pod names, field slugs, relationships, storage choices, and any templates or shortcodes that depend on them. That keeps future migrations understandable and reduces the risk of breaking front-end output when a field is renamed.

Also test imports and relationship queries on a representative staging dataset before changing storage strategies on an established Pods site.

For larger datasets, decide deliberately whether each record should remain a normal WordPress post or use Pods Advanced Content Types. That choice affects query behavior, theme compatibility, imports, exports, and the work required if the site later moves to another framework.