Link and sync ACF fields across pages (without environment sync)
Agencies ask for the same block of ACF content on more than one page all the time. A telephone number in the header and the contact page. A seasonal CTA on About and Services. A disclaimer that legal wants identical on every landing page except Home.
The usual answers are bad in different ways.
You duplicate the fields and tell editors to keep them in sync. They will not. You put the values on an options page and force every template to read from there. Then Home needs a different CTA and you are back to exceptions. You install a “global content” plugin that syncs everything, including the pages that should stay independent.
What you actually need is narrower: this field, on these pages, with one page as the source of truth, and the rest following on save. Other pages that use the same field keep their own values.
That is linking. It is not environment sync, and it is not a new field group.
Same field, different jobs
ACF location rules decide where a field appears. They do not decide whether two posts that both have that field should share a value.
So you can have cta_label on Home, About and Contact, all valid, all independent. That is correct when the three pages say different things. It is incorrect when About and Contact must show the same campaign line and Home must not.
The failure mode is editorial, not technical. Someone updates Contact and forgets About. Someone updates the options page and overwrites Home. Someone copies a page and ships a stale CTA because the duplicate was never in the set.
A linked set is a deliberate exception to independence:
- One source page holds the canonical value.
- You choose the pages that should receive it. Not “all pages with this field”.
- A sync copies the current value to those pages now.
- Later saves on the source update the linked copies.
- The same field can belong to other sets elsewhere, with a different source.
About and Contact can share a CTA. Home keeps its own. Services can be in a second set that shares a different CTA with a campaign landing page. Nothing about that requires a new ACF field.
Why “just use an options page” falls over
Options pages are the right tool for values that are truly site-wide: company name, default social links, a global alert that really does appear on every route.
They are the wrong tool when:
- Only some pages should share the value.
- The field already exists on the page for layout reasons, and moving it to options would break the template.
- Editors think in pages, not in a hidden options screen.
- Different clusters of pages need different shared values for the same field name.
Once you have two or three of those constraints, an options page becomes a second content model that the original ACF group still has to live alongside. You have not removed duplication. You have moved it.
Reusable blocks and synced patterns have the same shape of problem. They help when the design system is block-native. They do not help when the content already lives in ACF on page-shaped posts, which is the majority of ACF Pro sites we still see.
Link and Sync is not Nought Sync
This is the confusion that wastes the most time on a call.
FieldCraft Link & Sync shares the value of one ACF field across selected pages on the same site. The source is a page. The targets are other pages. Saving the source updates the linked copies. You can have independent sets for the same field.
Nought Sync moves selected WordPress changes between environments — local, staging, production. It is how a field-group change, a set of posts, or a media item gets to another environment without cloning the whole database.
They can appear in the same week of work. They are not the same product surface.
A typical mistake is to “sync” a CTA by copying the production database to staging, editing one page, and pushing the whole table back. That will move the CTA. It will also move drafts, orders, and anything else that changed. Another mistake is to treat FieldCraft Link & Sync as a deployment tool and wonder why staging still has yesterday’s schema.
Use Link & Sync when the editorial question is “which pages on this site should show the same ACF value?”. Use environment sync when the operations question is “which changes should leave this environment?”.
How a linked set should behave
If you are going to share a field across pages, the rules have to be boring and visible.
Selection is explicit. You pick the source, then you pick the targets. “Every page that has this field” is how you accidentally overwrite Home.
The first sync is a copy, not a merge. The source value wins for that field on the chosen pages. If a target already has a different value, that is a collision you should see before anything is written.
Later updates follow the source. Editors change the source page. Linked copies update on save. They should not silently diverge because someone edited a target “just this once” unless you have a way to break the link.
Sets are independent. The same ACF field can have more than one linked set. About+Contact is not Services+Campaign. Mixing them into one global link recreates the options-page problem.
Only the field you named moves. Linking cta_label must not rewrite hero_image on the same pages. Partial updates are the point.
It is reversible. Unlinking should not delete content. It should stop future updates. The copies keep whatever they last received unless you choose otherwise.
FieldCraft implements that model in WordPress admin: choose a source page, choose an ACF field, choose the pages in the set, sync the current value, then keep those pages updated when the source is saved. Preview still matters, because a wrong set is a content incident, not a schema incident.
When you should refuse to link
Not every duplicated string should be linked.
Do not link fields that are only coincidentally similar. Two pages can both have a heading called intro_title without sharing a headline.
Do not link fields whose values are supposed to be translated independently under WPML or Polylang unless the linking tool understands translations. Copying English into a translated post is not localisation.
Do not link as a substitute for a design-system component. If twenty landing pages share a layout, the long-term fix may be a block, a pattern, or a dedicated post type — not a web of field links.
Do not link across post types that store the field under different key paths without checking. A page and a product can both “have” cta_label and still not be the same meta.
Linking is for the cases where the content is the same on purpose, the field already exists, and the set is small enough that an editor can name the members.
A practical editorial workflow
For a shared campaign CTA on About and Contact:
- Confirm the field exists on both pages and on Home.
- Decide that About is the source — usually the page the campaign owner actually edits.
- Add Contact to the set. Leave Home out.
- Preview the copy. If Contact currently has different copy, that is a decision, not a surprise.
- Sync once.
- Tell the client: change the CTA on About. Contact will follow. Home will not.
- When the campaign ends, either update the source or unlink and let the pages diverge again.
For a telephone number that really is global, consider an options page instead. Linking twenty pages one by one is the wrong shape.
For a field you are also about to rename or move between groups, finish the schema migration first. Linking a field whose key is about to change is how you sync the wrong meta.
The rule
Sharing ACF content across pages is an editorial relationship, not a field-group setting and not a deployment. Name the source, name the members, copy on purpose, keep future saves in step, and leave every other page that uses the same field alone.
If your current method is “remember to paste it twice”, you do not have a method.