Social presence

Link previews, and what a blank one costs you

When someone pastes your address into WhatsApp, LinkedIn or Slack, the preview those apps build comes from a few lines of markup in the head of your page. If they are missing, the message shows a bare link, and the click has to be earned twice.

What a pasted link shows

A share preview is not made by the person sharing. The app fetches your page and reads Open Graph tags — og:title, og:description and og:image — written into the head. Your design, your logo and your homepage are not consulted. If those lines are absent there is nothing to build a card from, so the message shows a bare address and whatever the recipient already thinks of you.

The engine reads the page the way a visitor's browser receives it, after JavaScript has run, so tags injected by a CMS plugin or a tag manager are counted rather than missed. A missing og:title or og:description is a warning. A missing twitter:card tag is information, carrying the recommendation the code itself gives: summary_large_image.

The image is fetched, not just named

Most broken previews are broken at the image. The tag is present, so a checklist tool marks it done, and the file behind it is a 404, a redirect to a login page, or a host placeholder. The engine resolves the og:image address against the page it came from — a relative path is fine — fetches it with a 12-second timeout, and reads the first 4096 bytes. It counts as loading only if the response is HTTP 200 and the content type begins with image.

Those first bytes also carry the dimensions for PNG and JPEG files, read directly from the header. Under 600 pixels wide, or under 315 tall, is raised as information, with 1200x630 as the recommendation. For other formats — WebP, SVG, GIF — the dimensions are not read, and no size finding is raised at all rather than a guessed one.

A fetch we could not complete is our problem

If our request for your image fails, that is not evidence your image is broken. This project has been on the wrong end of exactly that: DNS filtering on the auditing machine once produced dozens of failed-network-request findings on client reports, against ordinary blocked trackers. The same interception would land on an og:image fetch and read as a defect on your site.

So a failed fetch raises no issue. The result is recorded as not checked, with the exception type kept in the details, so the gap in coverage is visible instead of being presented as a fault. A test locks it: with the network forced to fail, the audit must produce no image finding and must still record the reason.

Review stars, and why we will not add them

Structured data marked up as Review, AggregateRating or Rating is what allows a search result to carry stars. The engine looks for it in the page and records its absence as information, with the reason in plain words: a competitor showing stars beside your plain blue link wins that comparison before anyone reaches either site.

It is also the one recommendation in this category we will not implement on request. Review markup describes reviews that exist; writing it for reviews you have not received is fabrication, and Google's review snippet documentation requires the marked-up reviews to be visible on the page. The sample report carries this finding against our own site, left standing, for that reason. The fix is to collect real reviews first, then mark them up.

Where this sits in the report

Nothing in this category can be raised as critical. The strongest finding available here is a warning. In the shared weighting a warning counts 8 and information 3, against 20 for a critical, and the deduction saturates rather than subtracting flat, so the category never collapses to zero. In the overall score this category carries a weight of 0.6 — the lowest of any — because a missing share card does not stop anybody buying.

The impact ranking treats these as discovery problems, weight 1.4, below anything that blocks a sale or exposes data. The finding for missing social profile links matches no impact class at all, so it keeps a neutral weight of 1.0 rather than being quietly promoted or buried. On this site the category loses marks, and the findings are listed in full.

What the engine checks here

Each of these is a rule in the code, not a category heading.

og:title and og:descriptionRead from the rendered page. Either one missing raises a warning: without them a shared link has no headline and no summary, so the app falls back to the bare address. Both present with an image is what the engine records as complete share cards.
twitter:cardAbsent, this is information rather than a warning, with the recommendation to set summary_large_image. It governs the shape of the card on X, and other apps ignore it, which is why it is ranked below the Open Graph tags.
og:image is set at allNo og:image is a warning, with 1200x630 given as the size to aim for. This is the tag that decides whether a pasted link arrives as a picture or as a line of grey text.
og:image actually loadsThe address is resolved against the page and fetched with a 12-second timeout. It passes only on HTTP 200 with a content type beginning image. A tag pointing at a host's holding page returns HTML, not an image, and is reported as not loading — which is exactly the finding this engine raised against our own site before launch.
og:image dimensionsParsed from the header bytes of PNG and JPEG files, from the first 4096 bytes already fetched. Below 600 wide or below 315 tall is information: the card still appears, but scaled up and soft. Formats whose headers are not parsed produce no size finding rather than a guess.
Review or rating structured dataMatched on Review, AggregateRating or Rating in JSON-LD, or a microdata itemtype naming Review or AggregateRating. Absent, it is information. The recommendation is qualified in the code itself with "if applicable", and it is refused outright where there are no real reviews to describe.
Social profile linksEvery link on the page is scanned for nine hosts: facebook.com, twitter.com, x.com, instagram.com, linkedin.com, youtube.com, tiktok.com, pinterest.com and github.com. The ones found are listed in the report. None found is information.
Off-site brand mentionsNot checked, and recorded as not checked. Monitoring what is said about you elsewhere needs an external mention API, which this engine does not call, so the gap is written into the report rather than left to look like a clean result.

Questions

The preview looks fine when I share it. Why is this flagged?

Sharing platforms keep the card they built the first time they fetched your page, which is why Facebook publishes a Sharing Debugger and LinkedIn a Post Inspector, both of which fetch again on demand. The audit reads what is in your page today. If the two disagree, the platform is showing you an old card, and a first-time sharer will get the current one.

Can you add review stars to our search result?

Only if you have reviews. The markup has to describe reviews that are genuinely there for people to read, and Google's review snippet documentation requires them to be visible on the page. Writing the markup without them is inventing evidence, and it is the one recommendation in this report we decline to carry out. What we will do is help you get the reviews you already have onto your own page.

We do not use social media. Does the missing-profiles finding matter?

Barely, and the report is built so you can see that. It is information, worth 3 in the deduction against a category weighted 0.6 in the overall score, and it carries a neutral impact weight because the engine cannot classify it. Our own site has the same finding. It is there for completeness, not as something to act on.

Sources

Public and checkable. Nothing here rests on a number we cannot point at.

This is one of fifteen categories. You can read a real report this engine produced on this very site — including the findings it raised against us — or ask for an audit of yours.