Which tag is read by what
<title> and <meta name="description"> are the raw material for a search result. Open Graph — every tag beginning og: — is what Slack, Discord, Facebook, LinkedIn, iMessage and WhatsApp read when they expand a pasted link. Twitter Card tags are read by X, which falls back to Open Graph when they are absent, so the twitter: block is a refinement rather than a requirement. canonical names the one address you consider authoritative when the same content is reachable at several URLs.
Everything here is generated in the page. Nothing is fetched, uploaded or logged, which also means the tool cannot check that your image URL resolves or that your canonical points somewhere real.
Where the 60 and 155 come from
Neither limit is a character count in the specification, because neither engine truncates on characters. Titles are cut on rendered pixel width, roughly 600px on desktop, which works out around 55 to 60 characters in a typical mixed-case sentence and considerably fewer if you write in capitals or use wide letterforms. Descriptions are cut somewhere around 155 to 160 characters on desktop and shorter on mobile.
The more useful point is that the description is not guaranteed to be used at all. Search engines routinely ignore it and synthesise a snippet from the page body when that matches the query better. Treat it as the version you would like shown, write the important half first, and do not spend an afternoon tuning it to exactly 155.
og:image, and why the preview does not update
1200 x 630 is the size everything handles. Below about 300px on either edge most platforms drop to the small square card instead of the wide one. The URL has to be absolute and publicly reachable without a login or a cookie, because the crawler fetching it is not the visitor's browser and carries none of their session.
When you change the image and the old one keeps appearing, the cause is nearly always the platform's cache, not your markup. Each service keeps its own copy for days and each has its own way to purge it: Facebook's Sharing Debugger, LinkedIn's Post Inspector, and X's card validator. Slack and Discord expire on their own schedule with no public tool, and the practical workaround there is a new URL — a query string is enough.
Mistakes that survive review
| Written as | Should be | Effect |
|---|---|---|
<meta name="og:title"> | property="og:title" | Ignored entirely — OG uses property, not name |
og:image="/og.png" | Full https URL | Most unfurlers will not resolve it |
| Tags injected by client-side JS | Present in the server response | Unfurlers do not run your JavaScript |
| One shared description sitewide | One per page | Nothing distinguishes your pages in results |
hreflang pointing one way | Every version links to every version | Unreciprocated alternates are discarded |
The last one catches people the most often. If the English page lists the Spanish alternate, the Spanish page has to list the English one back, and both should list themselves. The generator adds the self-reference and an x-default for you, but it cannot write the tags that belong on the other pages.
Questions people ask
Do I still need a keywords meta tag?
No. Major engines stopped using it for ranking long ago and it has been an ignored field for well over a decade. Adding one does no harm and no good. The tag is omitted here because publishing your target keyword list to anyone who views source has a small competitive cost and zero upside.
My link preview shows the old image after I changed it.
That is a cache on the platform side, not a problem with your tags. Facebook, LinkedIn and X each publish a debugger that refetches on demand. Slack, Discord and iMessage do not, and expire on their own schedule. If you need it changed immediately, serve the link with a new query string so it counts as a new URL.
Which og:type should I pick?
website covers most pages. article lets platforms read published and modified dates and an author, product enables price and availability where a platform supports it, and profile is for a person. Picking the wrong one is not penalised; it just means the extra fields go unread.
Does the canonical tag have to be an absolute URL?
It works either way in practice, but absolute is the safer habit. Relative canonicals are resolved against the current document, which means a page reachable at two paths can resolve the same relative canonical to two different addresses — exactly the ambiguity the tag exists to remove.