The WordPress Block Editor Just Got a Superpower
WordPress 6.5 introduced the Block Bindings API — a way to connect any block attribute to any data source. No custom blocks, no shortcodes, no PHP templates. Just standard WordPress blocks wired to dynamic data.
At Voyager Marketing, we built 12 custom binding sources on top of this API. Here is what that looks like in practice and why every WordPress agency should pay attention.
What Block Bindings Actually Do
A block binding replaces a block’s static content with dynamic data at render time. A paragraph block that says “Hello World” in the editor can display your company phone number, a visitor’s city name, or an AI-generated meta description on the frontend — all without JavaScript or custom PHP templates.
The binding is declared in the block’s metadata, not in custom code. This means any editor can use them. The content team doesn’t need to know PHP. They drop in a block, pick a source, and the data flows automatically.
Think of it like a spreadsheet formula. The cell shows a value, but the value comes from somewhere else. Change the source, every cell updates. That’s what bindings do for WordPress content.
How Bindings Compare to the Old Way
Before bindings, dynamic content in WordPress required one of three approaches — all with significant drawbacks:
| Approach | Problem |
|---|---|
| Shortcodes | Not visual in the editor. Breaks the WYSIWYG promise. Content editors see [phone_number] instead of the actual number. |
| Custom blocks | Requires a React developer. Every new data point means a new block. Maintenance scales linearly with features. |
| PHP templates | Content editors can’t touch them. Changes require a developer. No editor preview. |
| Block bindings | Uses standard core blocks. Visual in editor (shows fallback). Any attribute bindable. One source serves unlimited blocks. |
The key insight: bindings separate the data layer from the presentation layer without leaving the block editor. The content team designs with real blocks. The data fills in automatically at render time.
12 Sources We Built (And Why Each Matters)
Our ecosystem includes binding sources for every type of dynamic content a business website needs:
- Site data (15 keys) — Phone, email, address, hours, social links. Change once in Settings, updates in every header, footer, and CTA across the site.
- Post meta (77 fields) — Service-specific content across 8 CPTs with dot-notation JSON traversal for nested data like stats arrays.
- Ecosystem metrics (15 keys) — Live CPT counts, publishing velocity, freshness scores computed from SQL. Always-current proof numbers.
- Contextual CTAs (4 keys) — One pattern that adapts headline, text, and URL based on post type, city, and industry. Service area pages get city-specific CTAs automatically.
- Geolocation (6 keys) — Visitor IP to city name via CloudFlare headers with API fallback. Zero JavaScript, 24-hour cache, privacy-safe MD5 hashing.
- AI content (dynamic) — Orbit abilities generate content at render time with 24-hour transient caching. Meta descriptions, alt text, localized copy.
- Notion databases (14 types) — Edit a Notion row, WordPress page updates after cache expiry. Triple-layer caching for API rate limits.
- Analytics (8 keys) — GA4 and Search Console data from the Portal API. Pageviews, sessions, CTR, top queries displayed live.
- A/B testing (dynamic) — Cookie-sticky variant selection built into block markup. No third-party tools, no JavaScript, no flicker.
- Conditional content (6 rules) — Show different text based on business hours, day of week, post age, login status, or month.
See all 12 sources in action with live demos →
Real-World Performance and Caching
Bindings add zero overhead for cached sources (site-data, post-meta, contextual-cta). For sources that make external API calls (Notion, Analytics, AI), a multi-layer caching strategy prevents performance issues:
- Layer 1: In-memory static cache — survives within a single request. If 10 blocks on one page bind to the same Notion row, only 1 API call fires.
- Layer 2: WordPress transients — persists across requests. Notion caches for 1 hour, AI content for 24 hours, Analytics for 4 hours.
- Layer 3: External API — only fires on cache miss. Rate-limited to 30 calls/minute to prevent stampedes.
The result: a page with 15 bound blocks loads in the same time as a static page, because every binding resolves from cache on warm requests.
The Business Case: 90 Pages, One Pattern
We used block bindings to generate 90 pSEO landing pages — each with a unique H1, unique body copy, unique FAQ answers, and a phone number that updates from a single settings field. Traditional approach: 90 templates, 180 hours, $9,000. Our approach: 3 pattern templates, 4 hours, $0 per page ongoing.
See the full cost breakdown on our ecosystem value page.
Key Takeaways
- Block bindings are in WordPress core — this is not a plugin feature that might disappear. It’s the platform’s future.
- They replace shortcodes, custom blocks, and PHP templates with a single, standard approach that content editors can use.
- Performance is a solved problem — multi-layer caching means dynamic content doesn’t mean slow pages.
- The competitive advantage is composability — combining multiple sources on one page creates personalization that no single tool can match.
- Start now — agencies that build on bindings today have a structural advantage. The API is stable. The patterns are proven.
Talk to us about implementing block bindings for your agency.
Leave a Reply