improvement(seo): noindex landing OG image endpoints via X-Robots-Tag

[waleedlatif1]

Summary

• Sets X-Robots-Tag: noindex on the shared landing OG image helper, covering all five models/integrations opengraph-image endpoints
• Keeps those social-card assets out of search results while leaving them fetchable, so Slack/LinkedIn/Facebook unfurls still render
• Replaces a proposed robots.txt Disallow for the same paths, which would have blocked the fetch itself and broken previews

Context

An external SEO recommendation asked for six new robots.txt rules. Checked each against GSC and the codebase:

Proposed rule	Verdict
Disallow: /api/og?*	Dead route; already covered by Disallow: /api/
Disallow: /favicon.ico?*	No crawl or index problem to solve
Disallow: /*?*tag=	Harmful. /blog?tag=* already serves noindex, follow + canonical to /blog. A robots block stops Google seeing the noindex, freezing ~890 impressions/qtr of tag URLs in the index instead of dropping them
Disallow: /*/tags*	Harmful. /blog/tags and /library/tags are listed in sitemap.ts as intentional hub pages
Disallow: /models/*/opengraph-image	Real intent, wrong mechanism — shipped here as X-Robots-Tag instead
Disallow: /integrations/*/opengraph-image	Same

robots.ts is unchanged.

Type of Change

• Improvement

Testing

Typecheck clean. Verified live that /blog?tag=n8n already returns noindex, follow with a canonical to /blog, and that all five landing OG routes go through createLandingOgImage.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 31, 2026 7:26pm

[cursor]

PR Summary

Low Risk
Single SEO header on OG image metadata routes; no auth, data, or user-facing page behavior changes.

Overview
Adds X-Robots-Tag: noindex on responses from the shared createLandingOgImage helper in og-utils.tsx, so every landing models and integrations opengraph-image route inherits the header in one place.

That keeps social-card image URLs out of search results without blocking crawlers or unfurl bots from fetching the PNG—unlike a robots.txt Disallow, which would break Slack/LinkedIn/Facebook previews. Inline comments in the helper document that tradeoff.

^{Reviewed by Cursor Bugbot for commit 7e19f3e. Configure here.}

[greptile-apps]

Greptile Summary

Adds an X-Robots-Tag: noindex response header to the shared landing-page Open Graph image helper.

• Applies the directive to all social-card image routes using createLandingOgImage.
• Keeps image assets fetchable by link-preview crawlers while discouraging search indexing.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The shared helper remains limited to Open Graph image routes, and the added response header matches the intended indexing behavior without blocking asset retrieval.

Important Files Changed

Filename	Overview
apps/sim/app/(landing)/og-utils.tsx	Adds a static noindex header to generated Open Graph image responses without changing image rendering behavior.

_{Reviews (1): Last reviewed commit: "improvement(seo): noindex landing OG ima..." | Re-trigger Greptile}

[waleedlatif1]

Closing this — deeper research shows the change is counterproductive.

Why the X-Robots-Tag: noindex approach is wrong: Google's Article structured data docs state plainly: "Image URLs must be crawlable and indexable." Discover guidance confirms og:image feeds thumbnail selection. Marking these endpoints noindex makes them non-indexable and risks Search/Discover thumbnail eligibility across every /models/* and /integrations/* page — to solve a problem worth 2 impressions and 0 clicks last quarter. Bad trade.

The same reasoning kills the originally proposed Disallow: /models/*/opengraph-image — robots.txt blocks the crawl, which fails the same requirement even harder.

Correction to the original PR description: I claimed a robots.txt block would break Slack unfurls. That was wrong — Slack states explicitly it does not honor robots.txt. Facebook mostly honors it and LinkedInBot does, so a preview risk exists there, but the Google crawlability requirement is the decisive argument, not the unfurl one.

The ?tag= and /*/tags* findings are unaffected and still stand.

Net result: robots.txt and the OG helper both stay as-is.