Shared Website Links: Specify the Preview Card, Not Just the Page Heading

When someone shares a public page, the title and image attached to the link should identify that particular page. Do not assume the visible heading or homepage artwork automatically defines the shared preview. Include preview metadata in the content brief and test the public URL in the receiving services you actually intend to support.

This is about representing an already public page when its address is shared. It is not a method for distributing private drafts, a social-posting service or a promise of more clicks.

Give each page its own identity

The Open Graph protocol defines basic metadata placed in the document head. Its four required properties describe an object's title, type, representative image and canonical identifying URL. It also defines an optional short description and site name.

For a business website, the useful commissioning question is simple: does this card describe the page someone chose to share, or does every link look like the homepage? A service overview and a detailed guide may belong to the same business while needing different titles and representative images.

The protocol defines metadata fields, not a universal layout for every receiving application. Do not treat a correct set of tags as a guarantee that all services display the same card, show every field or crop the image identically.

Separate the shared title from other uses of a title

A page heading belongs to the page itself. Open Graph defines a title for the object as it appears in the graph. They can be consistent without requiring identical wording in every context.

My recommendation is to write the shared title and description alongside the visible page copy. They should describe the same actual content, not promise a result that the page does not support. Avoid using the preview as an extra place for unverified awards, invented urgency or claims omitted from the page.

Keep ownership clear. If a content editor changes a page's purpose, somebody must also review the preview fields. A headline revision should not leave an unrelated old card describing a service that no longer appears on the destination.

Choose an image that still represents the destination

The protocol's image property identifies an image URL representing the object. It additionally supports properties for image dimensions, type and a description of what is in the image. It says that an image should have the corresponding image-alt property; that description is not a caption.

As a project requirement, select artwork that remains understandable when the receiving service presents it differently from your website. Important wording baked into the far edge of a picture may disappear in a crop. Ask for a review in the supported destinations rather than relying only on an editor's mock-up.

Use only material authorised for public distribution. A preview image is not an appropriate place for customer records, private dashboard screenshots or confidential workplace information. When artwork is replaced, confirm that the metadata now identifies the approved public asset.

Check the identifying URL and language together

Open Graph describes its URL field as the canonical URL used as the object's permanent identity. Agree which public page represents the content before generating that field. A copied template should not keep pointing every guide at the homepage.

The protocol also defines locale and alternate-locale fields. Use them only to describe real content availability. A translated title attached to an English-only destination does not create a translated page.

My practical recommendation is to check the shared title, description, image and destination as one set for each supported language. The customer should not follow a German card into an unrelated English page simply because the template reused an old URL.

Include preview behaviour in the handover

Request a small acceptance set: a service page, a guide, a page with its own artwork and a page using an explicitly approved fallback image. For each, inspect the metadata served by the exact public URL and compare it with the intended content.

Then agree where a receiving-service preview will be checked and who owns follow-up if its displayed card differs. Record the observed result and time. An external preview is a separate observation from the bytes currently served by your site; do not promise immediate refresh everywhere or invent a universal cache lifetime from the Open Graph specification.

Also test the destination itself. An attractive card does not excuse a broken link, an unexpected access wall or a page whose main content contradicts the preview.

Discuss these fields as part of a website brief rather than adding them as unexplained technical leftovers at launch. The protocol supplies the vocabulary. Page-specific wording, public artwork, language consistency and actual receiving-service checks make that vocabulary useful. No platform account access or posting is needed to define those requirements.