Search and Share

On-page SEO checklist

Run this for each page template (home, category, product, article, landing page) and for your ten most important pages. Most problems live in templates, so fixing a template fixes hundreds of pages at once.

Crawlable and indexable

• The page returns status 200 to a plain request (no login, no geo-block, no bot challenge for search crawlers).
• It isn't blocked by robots.txt.
• It has no noindex in a meta tag or X-Robots-Tag header, unless intended.
• The main content is in the HTML the server sends, or renders reliably with JavaScript. Check with "View source" and with the URL Inspection tool in Search Console.
• Internal links are real <a href="..."> links, not click handlers on divs or buttons.
• The page is reachable within a few clicks of the home page.
• It is listed in the sitemap.

One URL per page

• <link rel="canonical"> is present, absolute, and points to the preferred URL of this page.
• http:// and https://, www and non-www, and trailing slash variants all redirect (301) to the one canonical form.
• URLs with tracking parameters (utm_ and similar) canonicalise to the clean URL.
• Paginated pages (?page=2) canonicalise to themselves, not to page 1.
• Filtered or sorted versions either canonicalise to the main listing or are blocked from crawling, by a deliberate choice.
• There is no duplicate copy of the site on another host (staging, an old domain, an IP address) that is indexable.

Titles, descriptions and headings

• Unique <title> and meta description (see titles-and-descriptions.md).
• Exactly one <h1>, describing the page's main topic.
• Headings (h2, h3) follow the structure of the content and aren't used just for styling.
• The main topic appears naturally in the title, H1, opening paragraph and URL.

Content

• The page answers the question it's meant to answer, near the top.
• It has enough substance to be useful on its own. Thin pages (a heading and two lines) are better merged or set to noindex.
• The content isn't copied from another page on your site or elsewhere. Manufacturer descriptions copied by every shop are a common example.
• Dates are shown on time-sensitive content, and the content is kept up to date.
• Author or organisation details are shown where trust matters (health, money, legal, reviews).
• Spelling and grammar are checked.

Links

• Each important page receives internal links from related pages, with descriptive anchor text ("widget sizing guide", not "click here").
• No broken internal links (404).
• No internal links that go through redirects. Link straight to the final URL.
• External links to sources are fine. Sponsored or user-generated links carry rel="sponsored" or rel="ugc".
• Breadcrumbs on deep pages, matching the site structure.

Images and media

• Meaningful images have descriptive alt text. Decorative images have alt="".
• File names are descriptive (blue-widget-side.jpg, not IMG_0042.jpg).
• Images are sized for their display size and served in a modern format where supported.
• width and height attributes are set to prevent layout shifts.
• Below-the-fold images use loading="lazy". The main image near the top doesn't.
• Videos have a title, description and thumbnail, and a text summary or transcript on the page.

Structured data

• The relevant JSON-LD template from structured-data/ is on the page.
• It passes the Rich Results Test with no errors.
• Every value matches what's visible on the page.

Performance and experience

• Core Web Vitals pass on mobile in the field data (Search Console or PageSpeed Insights): Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
• The page works and reads well on a phone without zooming.
• No intrusive pop-ups covering the content on mobile, especially on arrival from search.
• HTTPS with a valid certificate, no mixed-content warnings.

Sharing

• Open Graph tags are present with a page-specific title, description and image (see head-tags-guide.md).
• The share image meets the guidance in share-image-sizes.md.
• Paste the URL into a chat app and check the card.

International (if relevant)

• Each language version has its own URL.
• hreflang annotations are complete and reciprocal, with x-default.
• The lang attribute on <html> matches the page language.
• Visitors aren't forced to a language version based on IP address alone. Offer a switcher instead.

Template review record

| Template | Example URL | Reviewer | Date | Issues found | Fixed |
|---|---|---|---|---|---|
| Home | | | | | |
| Category | | | | | |
| Product | | | | | |
| Article | | | | | |
| Landing page | | | | | |

Share image sizes

When someone shares your link, most platforms show a card with an image, title and description. The image comes from your og:image tag (or twitter:image on X, if set). This page gives sizes that work across platforms, safe zones so nothing important gets cropped, and file advice.

Platforms change these often, and many don't publish exact specs. The values below reflect common published guidance as of October 2026. Rows marked Changes often are the ones most likely to move. Confirm with each platform's current documentation or preview tool before a big launch.

The short answer

Make one image per page at 1200 x 630 px, PNG or JPEG, under 1 MB (under 300 KB if you care about WhatsApp), with the key content inside the centre 630 x 630 px square. That works well almost everywhere.

By platform

| Platform | Recommended size | Aspect ratio | Minimum | Max file size | Notes | Stability |
|---|---|---|---|---|---|---|
| Open Graph (general) | 1200 x 630 | 1.91:1 | 600 x 315 for large cards | Keep under 1 MB | The baseline most platforms read | Stable |
| Facebook | 1200 x 630 | 1.91:1 | 600 x 315 for a large card; smaller images show as a thumbnail | 8 MB | Caches aggressively. Use the Sharing Debugger to refresh | Stable |
| LinkedIn | 1200 x 627 | 1.91:1 | 1200 wide recommended | 5 MB | 1200 x 630 looks the same. Use Post Inspector to refresh the cache | Changes often |
| X, `summary_large_image` | 1200 x 628 | about 1.91:1 (displays close to 2:1) | 300 x 157 | 5 MB | Reads `og:image` if no `twitter:image`. Has shown cards with the title over the image, so keep text away from the bottom edge | Changes often |
| X, `summary` | 240 x 240 or larger | 1:1 | 144 x 144 | 5 MB | Small square thumbnail beside the text | Changes often |
| Slack | Uses Open Graph | 1.91:1 | No published minimum | No published limit | Shows a smaller image in unfurls. Text in the image must still be readable at a small size | Changes often |
| Discord | Uses Open Graph | 1.91:1 | No published minimum | No published limit | Large image for `summary_large_image`, otherwise a thumbnail. `theme-color` sets the embed's accent colour | Changes often |
| WhatsApp | Uses Open Graph | 1.91:1, often shown as a square thumbnail | No published minimum | Images over about 300 KB may not show | Often crops to a centre square. File size is the most common reason previews fail | Changes often |
| iMessage | Uses Open Graph | 1.91:1 | No published minimum | No published limit | Shows large previews. Also uses your `apple-touch-icon` in some layouts | Changes often |
| Telegram | Uses Open Graph | 1.91:1 | No published minimum | No published limit | Large image when wide enough, otherwise a thumbnail | Changes often |
| Pinterest | 1000 x 1500 | 2:3 | 600 wide | 20 MB | Uses a tall image. Set a separate pin image on the page if Pinterest matters to you | Changes often |
| Fediverse servers | Uses Open Graph | 1.91:1 | No published minimum | Set by each server | Fetched by each server separately | Changes often |

Safe zones

Different platforms crop the same image differently. Design for the smallest common area.

+------------------------------------------------------------+
|                         1200 x 630                         |
|          +--------------------------------------+          |
|          |      Text-safe area: 1080 x 550      |          |
|          |   +----------------------------+     |          |
|          |   |  Centre square: 630 x 630  |     |          |
|          |   |  (logo, key words, face)   |     |          |
|          |   +----------------------------+     |          |
|          +--------------------------------------+          |
+------------------------------------------------------------+

• Centre square (630 x 630): the part that survives square crops in WhatsApp, some LinkedIn layouts and small thumbnails. Put your logo, the main subject or the two or three most important words here.
• Text-safe area (1080 x 550): leave at least 60 px on the left and right and 40 px top and bottom clear of text. Rounded corners and overlays eat into the edges.
• Bottom strip: some platforms overlay the title or domain along the bottom. Avoid putting important text in the lowest 80 px.

Text on share images

• Use large type: at least 48 px for headlines at 1200 px wide. Cards are often shown at a quarter of that width.
• Keep it to about six words. The card already shows the page title next to the image.
• High contrast. Many apps show the card on both light and dark backgrounds.
• Don't repeat the title word for word. Use the image for a visual, a key number from the page, or your brand.

File advice

| Choice | Advice |
|---|---|
| Format | PNG for text, logos and flat graphics. JPEG for photos. WebP is widely supported now, but some older crawlers and apps still skip it. Use PNG or JPEG for the `og:image` to be safe |
| Size | Aim for under 300 KB. Over 1 MB is slower to fetch and some platforms give up |
| Colour | sRGB. Other colour profiles can look washed out |
| Transparency | Avoid. Transparent areas can render black or white depending on the app |
| URL | Absolute HTTPS URL, publicly reachable, not blocked by `robots.txt`, fast to respond |
| Changes | Give a changed image a new file name (`share-v2.png`). Platforms cache by URL, sometimes for weeks |

Per page or one for the whole site?

• At minimum, one site-wide default image.
• For pages people actually share (articles, products, launch pages), a specific image converts much better than a logo.
• For large sites, generate images from a template at build time: page title, a short subtitle and your brand on a consistent background.

Check before launch

• og:image URL opens directly in a private browser window.
• og:image:width and og:image:height match the real file.
• og:image:alt describes the image.
• Paste the URL into Facebook's Sharing Debugger and LinkedIn's Post Inspector.
• Send the link to yourself on WhatsApp, iMessage and your team chat, and look at the result on a phone.
• After changing the image, refresh the platforms' caches with their debuggers.

Structured data guide

Structured data is a block of JSON-LD in your page that describes what the page is about in a format machines can read: this is an article by this person, this is a product at this price, this business opens at nine. Search engines use it to understand pages and, for some types, to show richer results.

Each .json file in this folder is one template, valid JSON, ready to fill in.

How to add it to a page

Paste the JSON inside a script tag anywhere in the page, usually in the <head>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": []
}
</script>

Rules that apply to every template:

• Mark up what is visible. Every value must match something a visitor can see on the page. Prices, ratings, opening hours and FAQ answers that aren't on the page are against Google's guidelines and can lead to a manual action.
• Server-render it where you can. Google can read JSON-LD added by JavaScript, but other engines and tools may not.
• One page, several blocks is fine. An article page can have Article and BreadcrumbList. Keep each as its own script tag, or combine them in an @graph array.
• Delete what you don't use. Remove optional properties you can't fill truthfully, rather than leaving placeholders.
• Escape properly. Inside JSON, double quotes in text become \". If your template engine inserts values, use its JSON encoder, not plain string concatenation, so a quote in a product name can't break the page or inject script.

The templates

| File | Use on | What it can do in Google | Notes |
|---|---|---|---|
| `organization.json` | Home page or about page, once per site | Helps with the logo and details in knowledge panels | Use the `@id` (`https://example.com/#organization`) to reference it from other blocks instead of repeating details |
| `website.json` | Home page only | Helps Google pick your site name | Google retired the sitelinks search box in 2024, so `SearchAction` no longer shows a search box there. It is harmless and other consumers may use it. Remove it if you have no site search |
| `article.json` | Blog posts, news, guides | Better title, date and image handling in results and news surfaces | `headline` should match the visible H1. Use real author pages for `author.url`. Images in 16:9, 4:3 and 1:1, at least 1200 px wide |
| `product.json` | Product detail pages | Price, availability, shipping and returns in results and shopping surfaces | Every offer value must match the page. Update `availability` when stock changes. Remove `gtin13` if you have no barcode number |
| `faq-page.json` | A page whose main content is a list of questions and answers | Since 2023 Google shows FAQ rich results only for well-known government and health sites | Still valid markup that other engines and tools read. Don't use it for user-submitted Q&A (that is `QAPage`) or for marketing copy in question form |
| `breadcrumb-list.json` | Any page below the home page | Can replace the URL in results with a readable trail; where it shows varies by device and changes over time | The last item has no `item` URL because it is the current page. Must match the visible breadcrumb trail |
| `local-business.json` | The home or contact page of a business with a physical location or service area | Supports local results, but your Google Business Profile matters far more | Use the most specific type that fits: `Restaurant`, `Dentist`, `Plumber`, `Store` and many more are listed on schema.org. One block per location, on that location's page |
| `software-application.json` | App or software landing page | Can show rating and price | Google expects `offers` and either `aggregateRating` or `review`. Only include ratings that are real and shown on the page. Use `MobileApplication` or `WebApplication` if more accurate |

Values that trip people up

• Dates: ISO 8601. 2026-10-18 or 2026-10-18T09:30:00+01:00. Include the time zone when you include a time.
• Prices: a number as a string or number, no currency symbol: "24.00", not "GBP 24" or a symbol. Currency goes in priceCurrency as a three-letter ISO code.
• Countries: two-letter ISO codes (GB, US, DE).
• Enumerations: availability, condition and return values are full schema.org URLs, such as https://schema.org/InStock.
• Images: absolute URLs that crawlers can fetch, not blocked by robots.txt, not behind a login.
• Telephone: international format with country code.
• Opening hours: 24-hour HH:MM. For a day you're closed, leave it out. For one-off holiday hours, add a block with validFrom and validThrough.

Connecting blocks with @id

Giving Organization and WebSite an @id lets other blocks point to them:

"publisher": { "@id": "https://example.com/#organization" }

This keeps details in one place. The @id is an identifier, not a page that needs to exist, but it should stay the same forever.

Test before and after deploying

1. Paste the code or URL into Google's Rich Results Test. It shows which rich results the page is eligible for and any errors.
2. Use the Schema Markup Validator (validator.schema.org) for general schema.org correctness, including types Google doesn't use.
3. After launch, check the Enhancements and Shopping sections in Google Search Console for errors across all pages.
4. Re-test after template changes. A broken loop in a template can empty every product's price at once.

What it can't do

• Structured data doesn't directly improve rankings.
• Eligibility for a rich result doesn't mean it will be shown. Search engines decide per query.
• The types and features search engines support change. Check the current search gallery in Google's documentation before relying on a specific rich result.