Open Graph Link Previews for an AI-Built App

Open Graph link previews are the small card of title, description and image that appears when someone pastes your app's link into a chat, a social post or a team workspace. When an AI-built app has none, the link shows up as a bare URL or a generic grey box, and nobody clicks it. The fix is a handful of tags in the page head, but there is one catch specific to apps built with modern front-end frameworks, and it decides whether the fix works at all.

What open graph link previews are built from

When you share a link, the platform fetches your page, reads some tags from the head, and builds the card. The format comes from the Open Graph protocol, which defines four required properties:

• og:title: the title of your object as it should appear within the graph.

• og:type: the object's category, such as website or article.

• og:image: an image URL that represents the page.

• og:url: the canonical URL, used as the page's permanent ID.

The protocol also describes og:description as a one to two sentence description, and says that if you specify an image you should also give og:image:alt. Width and height properties (og:image:width, og:image:height) let a crawler lay out the card without downloading the image first.

A complete head for a landing page looks like this:

<meta property="og:title" content="Booking made simple for dog groomers" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://example.com/" />
<meta property="og:image" content="https://example.com/og/home.jpg" />
<meta property="og:image:alt" content="A groomer trimming a small dog on a table" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:description" content="Online booking and reminders that cut no-shows." />

The catch for AI-built apps

Many apps generated by AI tools are single-page applications. The server sends an almost empty HTML file, and JavaScript builds the page in the browser, including any tags in the head. A person's browser runs that JavaScript, so everything looks right to you. Many link-preview crawlers read only the first HTML they are sent and do not run scripts, so for them the page has no title, no image, nothing.

That explains the most common report: "the tags are in my code but the preview is blank." The tags exist after JavaScript runs; the crawler never sees that stage. Some platforms do render JavaScript, but you cannot count on every chat app, social network and email client doing so.

Test what a crawler sees

Skip the guessing and fetch the raw HTML the way a crawler would, with no browser:

curl -s https://your-app.example/some-page | grep -i "og:"

If the output lists your tags, a script-free crawler can read them. If it prints nothing, the tags are only added in the browser and previews will fail. Run the same command on a deep page, such as a product or post URL, not only the home page, since that is what people actually share.

Ways to fix it

In order of effort:

1. Put the tags in the static HTML. For a site with a few fixed pages, write them straight into each page's head file. This is the simplest option and it works.

2. Use server-side rendering or static generation for pages that vary, like individual posts or listings. Ask your AI coding agent to render the head on the server for those routes, and then verify with the curl test above. Do not accept "done" until curl shows the tags.

3. Serve a small pre-rendered response for crawlers. This is more fragile and easy to get subtly wrong, so treat it as a last resort.

Whichever route you use, make og:url the canonical address of that exact page. A home-page URL on every route makes every shared link look identical.

The image is half the preview

An image-less card is easy to ignore. Practical points that hold across most platforms:

• Use an absolute URL starting with https://. A relative path like /og/home.jpg will not resolve for a crawler.

• Make the image publicly reachable without logging in.

• A landscape image around 1200 by 630 pixels is the widely used convention, and keeping key text away from the edges guards against cropping.

• Keep the file size modest so the crawler does not time out.

• Write real alt text. It helps people using assistive tools and the protocol asks for it.

Do not use a screenshot with tiny text; at card size it is unreadable. A clear photo or a short headline on a plain background works better.

Previews get cached

Platforms store the preview they first fetched, so fixing your tags may not change what an old link shows. Most platforms offer a way to re-fetch a URL in their sharing or debugging tools. If you have changed the image, a new file name is the surest way to get past stale caches, because the old URL no longer exists in anyone's memory.

Where this fits in launching an app

Previews matter most on launch day, when the first links get shared. Pair the tags with the basics of discovery in getting your AI app indexed by Google and the low-budget tactics in SEO for an AI-built app with no marketing budget. If you are about to announce, launching an AI app on Product Hunt covers what else to prepare, and a custom domain gives shared links a name people trust. For the full build path, see the guide to building an app with AI.

Frequently asked questions

Why is my og:image not showing?

Usually one of four things: the tag is added by JavaScript the crawler does not run, the image URL is relative, the image needs a login to load, or the platform is showing a cached older preview.

Do I need Open Graph tags if I already have meta tags for Google?

They are separate. Search engines read the title and description meta tags; link-preview cards use the Open Graph tags, so a page benefits from both.

What size should an Open Graph image be?

About 1200 by 630 pixels in landscape is the common convention. Check each platform you care about, since requirements vary.

Can an AI coding agent add these tags?

Yes, and it is a good use of one. Ask it to add them on the server side for dynamic pages, then confirm with the curl command instead of trusting its summary.