Server-side rendering (SSR) for public profile pages — currently not crawlable by search engines or AI
The Rebel Marketer
Public Beacons profile pages are rendered entirely client-side via JavaScript. When checking what's actually indexable, search engines and AI crawlers (ChatGPT, Perplexity, Gemini, etc.) can only read the meta tags — title, description, OG tags — not the actual page content (links, bio, services). This makes Beacons pages nearly invisible for organic search and AI-agent discoverability, which matters a lot for creators using Beacons as their main hub. Adding SSR or static pre-rendering (like Wix and other competitors have done) would significantly improve this without changing the page's look or functionality.
Jacob Choi-Durham
Hi The Rebel Marketer — thanks for flagging this, super helpful context. I’m going to share this with our team so they can take a closer look at the crawlability/SSR vs. pre-rendering piece, and we’ll follow up once we have more info.
The Rebel Marketer
Jacob Choi-Durham
Hi Jacob — happy to go deeper. Fetching the profile URL with a plain HTTP client (no JS execution, e.g. curl) returns an initial HTML payload with an empty root mount point — no server-rendered bio, links, or profile data in the DOM. Everything is injected client-side after the JS bundle loads and calls the profile API. Only the <head> meta shell (title, OG tags, description) is present pre-hydration.
Why this matters beyond "Google will render it eventually": Googlebot's JS rendering happens in a second, resource-budgeted wave and can lag or get deprioritized. More importantly, several AI crawlers (PerplexityBot, GPTBot, and similar) are simple HTTP fetchers that don't execute JS at all — for those, a client-side-only profile is functionally blank. Social preview bots behave the same way.
Fix options, roughly by effort:
Full SSR (Next.js, Nuxt, SvelteKit-style server rendering) — strongest, most implementation cost.
Static pre-rendering per profile — generate an HTML snapshot on save/update, serve that as the actual response to everyone, not just bots. Lower lift, works universally.
Dynamic rendering (interim) — detect crawler user-agents (Googlebot, PerplexityBot, GPTBot, ClaudeBot, facebookexternalhit) and serve them a pre-rendered snapshot via something like Prerender.io while humans get the JS app. Google treats this as a stopgap, not the ideal end state, but it's fast to ship.
Whichever route: the bot-served version must match the human version's content (no cloaking), and adding Person/ProfilePage JSON-LD to that server-rendered output would also give AI systems real entity clarity — not just crawlability.
Quick way to verify a fix: curl the URL directly and confirm bio/links show in raw HTML, check it in Google's URL Inspection tool, and test with a PerplexityBot/GPTBot user-agent.
Happy to share more diagnostic detail if useful.
The Rebel Marketer
Following up — this is a significant discoverability gap. I ran diagnostics on my own profile (beacons.ai/therebelmarketer): Googlebot and AI crawlers (Perplexity, Gemini) only ever see the meta tag shell, not actual profile content, links, or bio text. Competing "link in bio" tools with SSR or static pre-rendering are getting indexed and cited by AI answer engines while Beacons profiles are invisible to them. Even a lightweight pre-rendered snapshot (à la Prerender.io) for crawlers would fix this without a full SSR rewrite. Would love to see this prioritized — happy to share more diagnostic detail if helpful.