Structured data and Open Graph tags: the minimum every site needs

Two small blocks in the <head> of a page do a lot of quiet work. Structured data (JSON-LD) tells search engines in unambiguous terms what the page is and who is behind it. Open Graph tags decide what a link looks like when someone pastes it into LinkedIn, Slack, WhatsApp, Facebook or an iMessage thread. Neither one is a ranking trick. Both are cheap to get right and easy to get subtly wrong.

Structured data: the minimum

Every site benefits from two types on the homepage: Organization (who publishes the site) and WebSite (the site itself). Put them in one script block:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/assets/logo-512.png",
      "sameAs": [
        "https://www.linkedin.com/company/example-studio",
        "https://github.com/example-studio"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Example Studio",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}
</script>

Notes on the details that matter:

• The @id values are just stable identifiers; they let other blocks refer to the organisation without repeating it.
• logo should be a square or near-square image of at least 112×112 pixels, at an absolute URL that loads without login.
• sameAs lists official profiles only. It is a statement that those profiles are the same entity, not a place for every link you have.
• A local business should use the more specific type (Dentist, Restaurant, LocalBusiness) with address, telephone and openingHoursSpecification, matching what is printed on the page.

Page types: only when they are true

Beyond the homepage, add a type only when the page really is that thing, and only with data that is visible on the page.

Type	Use on	Key properties	Do not
Article / BlogPosting	Articles, guides, news	headline, datePublished, dateModified, author, image	Bump dateModified without changing content
Product with Offer	A page selling one product	name, image, offers.price, priceCurrency, availability	Mark up category pages as one product; add review ratings you did not collect
FAQPage	Pages with visible questions and answers	mainEntity of Question / acceptedAnswer	Mark up questions that are not on the page
BreadcrumbList	Any page with a breadcrumb trail	itemListElement with position, name, item	Invent a hierarchy the site does not have

Google limits which rich results it shows and has narrowed some of them over time — FAQ rich results, for example, are now shown only for a small set of authoritative government and health sites. Markup is still valid and still helps machines understand the page, but do not add it expecting a visual change in results. Markup that describes content not on the page can lead to a manual action for spammy structured data.

Validate before you ship

1. Rich Results Test (search.google.com/test/rich-results): paste a URL or code. It reports parsing errors and whether the page is eligible for Google's rich result types.
2. Schema Markup Validator (validator.schema.org): checks against the full schema.org vocabulary, including types Google does not use for rich results.
3. Search Console enhancement reports show errors across all pages once Google has crawled them.

The errors seen most often:

• A trailing comma after the last property — valid in JavaScript, invalid in JSON. The whole block is ignored.
• Curly quotes (“ ”) pasted from a word processor instead of straight quotes.
• Unescaped double quotes inside a value, often in a product name like 27" monitor. Escape as \".
• Two plugins each printing their own Organization with different names or logos.
• Relative URLs for logo or image.

The free SEO checker counts JSON-LD blocks on the homepage, lists the types it found, and flags blocks that fail to parse as JSON.

Open Graph: the four tags that matter

<meta property="og:title" content="Teeth whitening in Northfield — prices and options">
<meta property="og:description" content="In-chair and take-home whitening, what each costs and how long results last.">
<meta property="og:image" content="https://example.com/og/whitening.png">
<meta property="og:url" content="https://example.com/whitening">
<meta name="twitter:card" content="summary_large_image">

• og:image is the one people notice. Use 1200×630 pixels (a 1.91:1 ratio), PNG or JPEG, under about 5 MB, at an absolute https:// URL. Keep important text away from the edges; some apps crop to a square.
• The image must load for an anonymous visitor. Hotlink protection, a login wall, a bot challenge or a robots.txt rule that blocks the image path all produce a blank preview. Open the image URL in a private window to check.
• og:title can be more conversational than the <title>; it does not need the brand suffix.
• og:url should equal the canonical URL so shares are counted against one address.
• Add og:type (website or article) and og:site_name for completeness.

Platforms cache previews aggressively. After fixing tags, use the platform's own debugger (for example the Facebook Sharing Debugger or LinkedIn Post Inspector) to force a refresh; otherwise old previews can persist for days.

For sites with many pages, generating the OG image automatically from the page title — as DeskSEO does for its own guides — gives every page a distinct, readable preview without design work for each one.

A quick audit

1. Run the SEO checker on the homepage: it reports missing JSON-LD, JSON-LD syntax errors, missing og:title/og:description/og:image, and an og:image that fails to load.
2. Paste two or three key URLs into the Rich Results Test.
3. Share one link into a private chat with yourself and look at the preview on a phone.

Related reading: titles and meta descriptions, which feed the same previews, and canonical tags, which og:url should match.