Why Every Page Shows the Same Link Preview

When different pages all share the homepage title or image, inspect what each URL returns before blaming the platform cache. Often the page-specific metadata never reached the response.

Compare two real page responses

Choose two pages that should have different previews, such as two products. Fetch each URL directly, without navigating from your homepage:

curl -sS -L 'https://example.com/products/blue-mug'
curl -sS -L 'https://example.com/products/green-mug'

Compare the final destination, title, description, image URL, and og:url. These are example paths, not results from a customer's site. If both responses contain the same homepage values, the sharing service may simply be using what your website supplied.

If the returned values differ correctly, inspect whether the two URLs redirect to the same destination or declare the same object URL. If the only identical value is the image, check whether a shared brand image is intentional before treating that as a bug.

Look for a default in the shared template

Many sites set a title and image in a root template or layout. A detail page may inherit those values when a CMS field is empty, the record lookup fails, or metadata is generated before the record is available.

Trace the value from the content record to the returned HTML. Check the published record rather than an editor's draft. For a CMS, inspect the page-specific SEO or social fields and how the theme chooses fallbacks. Changing a global setting usually changes every page using that fallback.

A title ending with the same site name is normal. An entirely identical product title across unrelated product pages deserves inspection. The Open Graph setup guide explains where metadata belongs in common website setups.

Check whether the host serves one HTML shell

In a client-rendered application, the browser can show different page content after navigation while the server returns the same shell for every route. A head library can make DevTools appear correct without changing that initial response.

Use the React and Vite metadata guide if this matches your setup. The fix is to provide page-specific metadata in the HTML response through static generation, prerendering, or server rendering. It is not necessary to migrate frameworks before establishing the cause.

In Next.js, inspect the metadata produced for the actual route and any parent layout defaults. The Next.js setup guide and metadata caching guide cover configuration and stale output separately.

Give each distinct page the correct object URL

Inspect redirects, og:url, and the HTML canonical link together. They serve different purposes, but hardcoding the homepage into every detail page is a warning sign. The Open Graph protocol uses og:url to identify the object.

A product page should normally identify its own stable public URL. Remove transient tracking values from your intended identity only when they do not change the content. A query such as ?product=blue-mug may select a different product and cannot be discarded blindly.

If you deliberately redirect aliases to one page, the same preview can be expected. Decide whether the URLs represent different content before trying to force different cards.

Recheck a small sample after the fix

Test the homepage, two detail pages, and a page with missing optional metadata. That last case confirms your fallback still works. Check that the image describes the corresponding record and that no duplicate tags contradict the page-specific values.

Then preview each public URL in Proovd. Once the fetched HTML is correct, request a fresh inspection on the relevant platform where supported. Existing shares can retain old information; editing metadata does not guarantee every historical post changes.

Keep cache troubleshooting as a separate final step. Otherwise a cache purge can appear ineffective even though the page has never stopped returning the homepage metadata.

References