# Open Graph not Working for Social Sites

**URL:** <https://forums.realmacsoftware.com/t/open-graph-not-working-for-social-sites/56629>\
**Category:** Elements\
**Created:** [June 12, 2026, 1:14pm UTC](https://forums.realmacsoftware.com/t/open-graph-not-working-for-social-sites/56629 "2026-06-12T13:14:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ercross](https://avatars.discourse-cdn.com/v4/letter/e/c57346/32.png) [@ercross](https://forums.realmacsoftware.com/u/ercross)\
**Post date:** [June 12, 2026, 1:14pm UTC](https://forums.realmacsoftware.com/t/open-graph-not-working-for-social-sites/56629/1 "2026-06-12T13:14:10Z")

</div>

Subject: Open Graph tags output literal {{item.\*}} tokens to crawlers on CMS collection-item pages

Hi Elements Support,

I’m seeing a problem where the Open Graph meta tags on my CMS collection-item (post) pages are not being resolved at publish time. The page delivers the literal token text (e.g. `{{item.title}}`) in the HTML head, so anything that does not run JavaScript — Facebook, LinkedIn, iMessage, X, etc. — never sees the real values. In a normal browser the page looks correct, because the tokens get filled in client-side, but social crawlers and link previews get the raw, unresolved tokens.

Site / setup

- Site: [https://followingpaul.org](https://followingpaul.org)
- Platform: Elements Platform v2 (RapidWeaver Elements, Pro license)
- Affected pages: the “Pastor’s Desk” post collection, item URLs like [Following Paul with WTBC - Following Paul Is Following Christ — and Not Following Paul Is Disobedience to Christ](https://followingpaul.org/pastor-s-desk/post/following-paul-is-following-christ)

My Open Graph configuration (on the Item page) The Open Graph component is enabled on the item page with these bindings, which I believe are correct:

- Type: Article
- Title: {{item.title}}
- Description: {{item.excerpt}}
- Image: {{item.image.src}}
- URL: {{item.canonicalURL}}
- Locale: en\_US
- Author: {{item.author}}
- Published: {{item.date}}
- Modified: {{item.date\_modified}}

The body of the page renders the item fields correctly, so the data binding itself works in the browser.

The problem (evidence) Running the post URL through Facebook’s Sharing Debugger (after “Scrape Again”) returns the tokens unresolved:

- og:title → Following Paul with WTBC - {{item.title}}
- og:description → {{item.excerpt}}
- og:image → inferred fallback ([https://followingpaul.org/resources/home\_images/pastor.jpeg](https://followingpaul.org/resources/home_images/pastor.jpeg)), because the served og:image value is the literal token {{item.image.src}} rather than a real URL
- Facebook also reports the “Inferred Property” warning for og:image, confirming it never received a usable og:image tag.

I can reproduce this directly in the page source: opening any live post and doing View Source (not DevTools/Inspect) shows the literal `{{item.title}}` and `{{item.image.src}}` text inside the head meta tags. This confirms the tokens are being resolved client-side after load, not written into the published HTML.

What I’ve tried

- Confirmed the live page returns the correct values when JavaScript runs.
- Re-scraped the URL in the Facebook Sharing Debugger multiple times — no change, because the served HTML head contains the literal tokens.

My question How do I get the Open Graph meta tags on CMS collection-item pages to be resolved server-side (pre-rendered / baked into the static HTML head) so that crawlers receive the real title, excerpt, and image? Is there a setting for static generation / pre-rendering of collection pages, or an Advanced option on the Open Graph component that controls this? If the configuration above is correct, what causes `{{item.*}}` tokens to render in the body but not be resolved in the head for non-JavaScript clients?

This affects every post I share, so I’d appreciate guidance on the correct fix.

Thank you, Edward R. Cross [followingpaul.org](http://followingpaul.org)

---

<div class="post-metadata">

**Author:** ![Pegasus](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/pegasus/32/25035_2.png) [@Pegasus](https://forums.realmacsoftware.com/u/Pegasus)\
**Post date:** [June 12, 2026, 1:23pm UTC](https://forums.realmacsoftware.com/t/open-graph-not-working-for-social-sites/56629/2 "2026-06-12T13:23:06Z")

</div>

This exact topic was already discussed today in another forum post. Attached is Dan’s response to it.

> [@AI is coming to Elements](https://forums.realmacsoftware.com/t/ai-is-coming-to-elements/56621/38):
>
> The Load More issue is something Ben can look into, we have a ticket for this and it’s scheduled for next week. The OG URL is a bigger issue, currently the CMS doesn’t know what Elements is outputting into the header as there’s no API for this. This is going to require us figuring out a nice solution so they can work more closely together. This will probably involve extending the Elements API. I have created a ticket internally for this, and it’s in the queue. I can’t say when this will make i…