A single-page app writes each route's Open Graph tags into the document head from JavaScript after the app mounts, yet every shared link still previews with the same site-wide title and image. Why does that happen, and what actually fixes it?

## The scraper is not a browser When a URL is shared, the receiving platform sends a small crawler to fetch it. That crawler's job is narrow: retrieve the response, parse the head, extract a handful of metadata values, and possibly fetch the image. It has no rendering engine budget to spare, no interest in your router, and no reason to wait for a JavaScript bundle to download, parse, execute, hydrate, resolve a data request and finally call an API that appends `<meta>` elements. The major link-preview scrapers do not execute page scripts at all. So the question "why is my card wrong" reduces to a mechanical one: **what bytes does the server return for this URL?** For a classic client-rendered SPA the answer is the same index shell for every route — one `<title>`, one generic `og:image`, an empty root element and a script tag. Every share of every route produces the same card because every route serves the same document. ## Why the usual workarounds do not work - **A head-management library.** These operate on the live DOM after the framework mounts. They are correct and useful for the browser tab and for in-app behaviour; they change nothing about the response body. - **Injecting the tags earlier, in an inline script before the bundle.** Still script execution, still skipped. - **Putting the tags in the body instead of the head.** The head is where scrapers look, and moving markup around inside a document the scraper already parsed without running scripts changes nothing. - **Hash routes.** A fragment is never sent to the server, so `example.com/#/article/42` cannot be answered with per-article metadata at all. Any site that needs previews needs real path-based URLs. ## What actually fixes it The per-route metadata must be in the HTML response: 1. **Server-side rendering.** The server resolves the route, looks up the record, and writes the `og:` block into the head of the response. This is the general answer and the one that also fixes titles for other consumers. 2. **Prerendering / static generation.** At build time, render every known route to its own HTML file with its own head. Ideal for content sites with a bounded, known set of URLs; less so for user-generated pages that appear after the build. 3. **A metadata-only server layer.** Some teams keep the app client-rendered but put a small server in front that, for every request, injects the correct head into the shell before responding. Everyone gets correct tags, which is preferable to the older practice of detecting scraper user agents and serving them a different document — user-agent sniffing is fragile, easy to get wrong, and serving crawlers different content than users is a practice search engines treat with suspicion. ## Adjacent breakage from the same root cause The same "scraper sees only the shell" fact explains several sibling symptoms: previews show the app's loading placeholder as the description; `og:image` points at a default logo on every article; a share of a deep link opens correctly in the browser but unfurls as the homepage. It also explains why the bug survives QA — every human tester follows the link in a real browser, where the client-side tags do apply and everything looks right. ## How to verify, concretely ```bash curl -sL https://example.com/blog/post-42 | grep -i 'og:' ``` This is the whole test. It fetches exactly what an anonymous, script-free client receives. If the per-route `og:title` and `og:image` are in that output, the markup side is done and any remaining problem lives on the platform (caching, image reachability). If they are not, the card cannot be fixed from the client. Do the same check against production rather than a local dev server, because the difference between a dev-mode render and the deployed response is often the whole story. ## The interview point The answer an interviewer is listening for is not a library name. It is the recognition that link metadata is part of the **response**, not part of the running application, and that the class of consumers who need it — chat unfurlers, social scrapers, previewers embedded in mail clients — never becomes a browser. Once you have said that, the choice between full SSR, prerendering, and a thin injection layer is an engineering tradeoff you can walk through on the merits.