ACF CONTENT MODEL WORKSHEET
WP Growth Labs | Version 1 | 20 October 2026
https://wpgrowthlabs.com/services/acf-wordpress-development/

Use this before estimating a new build or a change to an existing ACF website.
A content model records what information you keep, who edits it and where it
appears. ACF fields store information; templates or compatible integrations
decide how it is displayed.

Save a copy and fill in one record for each content type and one field entry
for each value. Plain-language answers are enough. Mark unknowns for review;
you do not need to choose technical field types before discussing the project.
Keep passwords, licence keys, private customer records and unapproved client
material out of this worksheet.

This is a blank planning resource, not a finished specification, an ACF import
file, a quote or evidence that any tests have passed.

1. PROJECT AND EDITORS

Project / public website:
New build, existing-site change or migration:
What editing problem needs to be solved:
People who edit / who approves changes:
Five most common editing tasks:
What must remain unchanged:
Design or sample-content links you have permission to share:
Decision owner / review date:

2. CONTENT TYPE — COPY FOR EACH KIND OF RECORD

Name (for example: project, service, location or article):
Purpose:
One page's content, a reusable record, or a site-wide setting:
Where the current information is stored:
Approximate number of records / expected growth:
Where it should appear on the website:
Who may create, edit, publish and remove a record:
How records should be selected, sorted or filtered in each location:
What should happen to listings and links when a record is unpublished:
Does this record need its own public URL? Who decides:
Migration required / source / person responsible:

3. FIELD ENTRY — COPY FOR EACH VALUE

Label an editor will recognise:
Purpose / example content:
Record or page that owns this value:
Other places that reuse it:
One value, a repeated list, or a reference to another record:
Required or optional, and why:
Allowed choices or useful length/format guidance:
What an empty value should show (hide, approved fallback or validation):
For an image: ownership, crop expectations and alternative-text responsibility:
For a related record: allowed items, order and unpublished-item behaviour:
Who can edit it / who reviews it:
Template or integration that displays it (developer to confirm):
Unresolved question / owner / decision date:

Do not copy shared content into multiple fields just because it appears on
multiple pages. Agree one owner for it and list each place that uses it.
Changing one shared record may affect several pages; make those effects clear.

4. ILLUSTRATIVE EXAMPLE — NOT A COMPLETED CLIENT PROJECT

Content type: Project
Purpose: Describe one approved piece of work.
Ownership: One project record; listings select or query that record.
Example value: Short project summary.
Used in: A portfolio card and a relevant service listing, if both are in scope.
Editing task: Change the summary in its owning record.
Expected review: Both agreed locations show the saved summary; an unrelated
project stays unchanged.
Empty-state decision: Ask whether to hide the summary or require it.
Actual result: NOT TESTED.

This example does not promise that an existing theme or page builder already
supports the proposed behaviour. Confirm the templates, supported fields and
any extra integration work with a developer.

5. ACCEPTANCE RECORD — COPY FOR EACH AGREED CHECK

Task:
Editor role / permitted test environment:
Sample record and content:
Steps:
Expected result:
Actual result: NOT TESTED
Evidence location:
Reviewer / date:
Issue / owner / retest date:

Suggested checks:
- Edit shared text once and inspect every agreed output location.
- Try short, long and empty content; check desktop and phone-width layouts.
- Add or reorder a repeated item and follow its links.
- Unpublish a related record on staging and check the agreed empty state.
- Demonstrate the agreed recovery method without altering production content.

Use PASS only after observing the expected result. Other useful outcomes are
NEEDS HELP, BLOCKED and NOT IN SCOPE. A phone-width preview does not replace
testing the actual device when the task depends on its keyboard or touch UI.

6. SCOPE AND HANDOVER DECISIONS

Content types, fields and templates included:
Existing fields or URLs that must be preserved:
Migration sample and reconciliation owner:
Dependencies / licences / renewal owner:
Backup, deployment and recovery responsibilities:
Editor guidance required:
Future layout or feature changes that need a separate estimate:
Outstanding decisions and who resolves them:

Bring the relevant answers, public site/design link and representative content
to the scope review. Access arrangements can be agreed separately; do not send
credentials in the enquiry.

Project discussion:
https://wpgrowthlabs.com/lets-talk/?type=agency

Related planning resources:
https://wpgrowthlabs.com/blog/a-clear-wordpress-brief/
https://wpgrowthlabs.com/blog/elementor-vs-acf-wordpress/
https://wpgrowthlabs.com/blog/wordpress-website-handover-checklist/

Official ACF background:
https://www.advancedcustomfields.com/resources/displaying-custom-field-values-in-your-theme/
https://www.advancedcustomfields.com/resources/relationship/