The dozen tags that decide what your link looks like
A page has two public faces it does not control directly. One is the search result: a title, a grey URL line, two lines of description. The other is the unfurled card that appears when somebody drops the link into Slack, WhatsApp, LinkedIn or a group chat. Both are assembled from a small block of markup in your <head>, and if that block is wrong the page still works perfectly while looking broken everywhere it gets shared.
The tags come from three different lineages, which is why the block looks so inconsistent. The title element and the description meta tag are as old as the web. rel="canonical" arrived in 2009 to tell search engines which URL is the real one when several serve the same content. The Open Graph protocol was published by Facebook in 2010 and uses property="og:..." rather than name="...", which is the single most common hand-typing mistake. Twitter Cards came a couple of years later with name="twitter:...", and X still reads Open Graph as a fallback, which is why so few sites bother writing a full second set.
Filling in the form
- Under Core, enter your page title, meta description and canonical URL. If the canonical does not begin with
http://orhttps://you get an inline warning, because a relative canonical is one of the quieter ways to confuse a crawler. - Under Open Graph, add an OG image URL and your site name, and set OG type to
articlefor a blog post orwebsitefor anything else. Leave OG title and description blank unless you want them to differ from the core fields. - Under Twitter / X Card, pick the card type and add your @handles. Type them however you like:
sysfenix,@sysfenixand even@@sysfenixall normalise to a single leading@. - Watch the four preview cards update as you type, then press Copy HTML and paste the block inside your
<head>.
Reading the Google preview honestly
Google truncates by pixel width, not by character count, which is why “keep it under 60 characters” is only ever a rough guide: a title full of capital letters and Ws runs out of room far sooner than one made of lowercase is and ls. The search preview here measures your text with a real canvas in your browser against roughly 600 pixels for the title and 920 for the description on desktop, using an Arial-family approximation of Google’s rendering.
Those numbers are estimates that the SEO community has converged on, not published limits, and Google has changed its font stack more than once. Treat a title that fits with room to spare as safe, a title that fits exactly as risky, and one that gets cut as something to shorten. The URL line is rendered the way Google shows it, hostname first and path segments separated by chevrons, so https://example.com/blog/my-post displays as example.com › blog › my-post. For a more thorough check, including the mobile widths, use the dedicated SERP Pixel Counter.
Which fields fall back to which
The fallback chain is the part people get wrong when writing this block by hand, and it is worth knowing even if you let the tool handle it. A blank OG title takes your plain title. A blank OG description takes your meta description. There is no separate OG URL field at all, because og:url should be your canonical URL and having two inputs for one value invites them to drift apart. The Twitter title, description and image mirror the resolved Open Graph values.
The practical consequence: you can produce a complete, correct block from three fields and an image URL. Everything else is refinement.
The ampersand that breaks a title
Every value you type is escaped before it lands in an attribute. This sounds like a detail until you write a title like Tips & Tricks for "Clean" HTML, which without escaping closes the content attribute early and leaves the rest of your title as stray markup in the head of the document. The escaping here reuses the same tested routine as our HTML Encode tool, so ampersands, angle brackets and quotes are converted to entities consistently in every generated tag.
summary or summary_large_image, and what is missing
The card type is the one aesthetic decision in the form. summary_large_image, the default, puts a wide image above the text and dominates a timeline; it wants an image around 1200 by 630 pixels. summary places a small square thumbnail beside the text, which some publishers prefer for link-heavy feeds. Both read the same twitter:image, so switching costs nothing but a re-scrape.
A few tags are deliberately out of scope, and hand-adding them is easy once you have the block. There is no og:image:width or og:image:height (helpful for making a card render before the crawler has finished fetching the image), no og:locale, and no article:published_time or article:author. Structured data is a separate job entirely: if you also want a rich result with a byline, a rating or an FAQ accordion, generate the JSON-LD with the Schema Markup Generator and put it in the same <head>. Nothing you type on this page is sent anywhere, which is worth knowing when you are drafting titles for a launch that has not been announced yet.
