Search and Share

Changelog

• 1.0.0, 22 October 2026: first release

Search and Share

Version 1.0.0

Everything a site needs so search engines can find and understand its pages, and so links look right when people share them. It has a complete head template, robots.txt and sitemap files, structured data templates for eight common page types, a share image size table with safe zones, a guide to writing titles and descriptions, and two checklists: one for each page and one for launch and indexing. Every JSON and XML file is valid as shipped.

Who it's for

• Site owners launching a new site or relaunching an old one
• Developers who build sites for clients and want a repeatable SEO and sharing setup
• Marketers who need to brief a developer on exactly which tags and files to add
• Anyone whose links show a blank card or the wrong image in chat apps

No SEO background is needed. Each file explains what to change and why.

How to use it in 5 minutes

1. Open head-tags.html, copy the tags into your page template and replace the [placeholders]. Read head-tags-guide.md for what you can remove.
2. Copy robots/robots.txt to your site root and change the paths and sitemap URL.
3. Make a 1200 x 630 px share image using share-image-sizes.md, and point og:image at it.
4. Pick the structured data templates that match your pages from structured-data/ and add them.
5. Before launch, work through launch-indexing-checklist.md from the top.

File map

A note on limits

This kit covers the technical and on-page groundwork. It can't make a page rank: that depends on the content, the competition and links from other sites, none of which a template controls. Search engines and social platforms change their rules and image sizes regularly, so confirm platform-specific details with their current documentation before a big launch.

Licence

MIT License. See LICENSE.txt.

Head tags guide

head-tags.html is a complete <head> for a typical page. Copy the tags into your layout or template, replace every [placeholder], and delete the lines you don't need. This guide explains each group so you know what is safe to remove.

Basics

Language alternates

Only keep the hreflang lines if the page exists in more than one language or region. Each language version lists every version, including itself, and x-default points to the version for everyone else (often a language picker or the main language). If your site is in one language, delete both lines.

Open Graph

Open Graph tags control the preview card when someone shares your link in chat apps, social networks and many other places. Most platforms read them, including Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage and Telegram.

X (Twitter) card

X reads Open Graph tags for title, description and image if its own tags are missing, so you only need:

• twitter:card set to summary_large_image for a wide image, or summary for a small square thumbnail
• twitter:site and twitter:creator if you have accounts to credit. Delete them if not

Theme colour and icons

• theme-color tints the browser interface on some mobile browsers. The two lines give separate light and dark values. Delete the media attribute and one line if you only want one colour.
• favicon.ico at 32 x 32 still matters for older browsers and some tools that fetch it directly.
• icon.svg gives a sharp icon at any size in modern browsers. It can include a dark mode style.
• apple-touch-icon.png is 180 x 180 px, with no transparency. It is used when someone adds your site to their home screen.
• site.webmanifest holds the app name and larger icons (192 and 512 px) for Android and installable web apps. Delete the line if you don't have one.

Structured data

The small WebPage block at the end is a safe default. For specific page types, replace it with one of the templates in structured-data/ (see structured-data/README.md).

Common mistakes

• Relative URLs in og:image or canonical. Both must be absolute.
• The same title and description on every page, usually because the template was never filled in.
• A canonical that points to the home page from every page, which tells search engines to ignore all your other pages.
• noindex left on from a staging site.
• Share images behind a login or blocked by robots.txt, so platforms can't fetch them.
• Tags added by JavaScript after the page loads. Many share crawlers don't run JavaScript, so tags must be in the HTML the server sends.

Check your work

1. View the page source (not the inspector) and confirm every tag is there with real values.
2. Paste the URL into each platform's preview or debugging tool where one exists, or send it to yourself in a chat app.
3. After changing a share image, use the platform's debugger to refresh its cache. Most platforms cache previews for days.

Launch and indexing checklist

For a new site, a redesign or a move to a new domain. Work through it in order. The "before launch" section catches the mistakes that are cheap to fix now and expensive to fix after search engines have crawled the wrong thing.

Site: [https://example.com] Launch date: [date] Owner: [name]

Before launch

Remove staging protections, on purpose

• Note every place staging blocks indexing: Disallow: / in robots.txt, noindex meta tags, X-Robots-Tag headers, password protection, CMS "discourage search engines" settings.
• Plan who removes each one at launch, and check them again an hour after launch.
• Confirm staging stays blocked and password-protected after launch, so it doesn't compete with the live site.

Domain and URLs

• Choose one canonical host (https://example.com or https://www.example.com) and redirect the other to it with a 301.
• http:// redirects to https:// in one hop.
• Trailing slash behaviour is consistent, with redirects for the other form.
• Custom 404 page returns real status 404, not 200.

Redesign or migration only

• Export every URL from the old site: from the old sitemap, analytics landing pages, Search Console's pages report and a crawl.
• Map every old URL to its new equivalent in a spreadsheet. Pages with no equivalent go to the closest relevant page, not all to the home page.
• Implement 301 redirects for every mapped URL, and test them in bulk before launch.
• Keep redirects in place for at least a year; longer is better.
• Keep the old domain registered and renewing if you're moving domains.
• Update internal links to point straight to new URLs, not through redirects.

On-page basics

• Every template passes seo-checklist.md.
• robots.txt is ready for production (see robots/robots-variants.md).
• sitemap.xml lists production URLs only (see sitemaps/sitemap-guide.md).
• Analytics is installed on production, respecting your consent setup.

Launch day

• Remove every staging block from the list above.
• Fetch https://example.com/robots.txt and read it. Confirm it is the production version.
• View the source of the home page and two inner pages. Confirm there is no noindex.
• Check response headers for X-Robots-Tag on HTML pages: curl -sI https://example.com/ | grep -i robots.
• Test ten old URLs (for a migration) and confirm each redirects to the right new page in one hop.

Google Search Console

• Add a Domain property (covers every subdomain and protocol). Verify it with the DNS TXT record Search Console gives you, at your DNS provider.
• If you can't edit DNS, add a URL-prefix property for https://example.com/ and verify it with an HTML file or meta tag.
• Add colleagues who need access with the lowest permission that works.
• Submit the sitemap: Indexing, Sitemaps, enter sitemap.xml, Submit.
• Use URL Inspection on the home page and two key pages. Check "Page is indexable", and click "Test live URL" then "View tested page" to see the rendered HTML and screenshot.
• Click "Request indexing" for the home page and your most important pages. There is a daily limit, so don't use it for every page; the sitemap handles the rest.
• For a domain move: use the Change of Address tool on the old property after redirects are live.

Bing Webmaster Tools

• Sign in and add the site. You can import sites directly from Google Search Console, which also verifies them.
• Otherwise, verify with a DNS record, an XML file or a meta tag.
• Submit the sitemap under Sitemaps.
• Use URL Inspection to check a key page.
• Consider IndexNow (supported by Bing and some other engines) so your CMS or build can notify them of changed URLs straight away. Many CMSs and hosts offer it as a setting or plugin.

Check rendering

Search engines need to see your content, not an empty app shell.

• In URL Inspection, "View tested page", check the rendered HTML contains your main text, links and structured data.
• Check the screenshot looks like the real page, not a loading spinner or a cookie wall covering everything.
• Look at "More info", "Page resources" for blocked or failed resources (CSS, JavaScript, API calls).
• Check that content which loads on scroll or click is also reachable through normal links, or present in the HTML.

Canonical issues to watch

In the Pages report (Indexing, Pages), these reasons point to canonical problems:

First four weeks

Expectations

• New sites can take days to weeks to be indexed, and longer to rank. A sitemap and Search Console speed up discovery, not ranking.
• Not every page will be indexed. Search engines skip pages they see as duplicates or low value.
• After a migration, some ranking movement for a few weeks is normal. A large, lasting drop usually means redirects, canonicals or indexability went wrong; recheck those first.

Sign-off

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

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

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

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.

Writing titles and descriptions

The page title and meta description are often the first words anyone reads from your site: in search results, in browser tabs, in bookmarks and in share cards. They decide whether someone clicks.

Length guidance

Search engines cut text by pixel width, not character count, so these are guides rather than hard limits. Wide letters (W, M) use more space than narrow ones (i, l).

Google rewrites titles and descriptions when it thinks another piece of text on the page matches the search better. You can't stop this, but titles and descriptions that accurately match the page are rewritten far less often.

Page titles

Pattern: [Specific topic or offer] | [Site name] or [Specific topic]: [Benefit or detail] | [Site name]

Rules:

• Unique on every page. Duplicate titles are the most common on-page problem.
• Lead with what the page is. "Blue Widget, 40 cm, Waterproof | Example Co" rather than "Example Co | Shop | Products | Blue Widget".
• Match the H1 closely, but it doesn't need to be identical. The H1 can be warmer; the title can be more specific.
• Use the words people search for, in natural order. If people search "widget repair near me", "Widget Repair in Leeds" beats "Restoring Your Beloved Gadgets".
• Brand at the end, separated by | or -. Drop it on long titles if space is tight; Google often shows your site name separately anyway.
• Home page: brand first is fine: "Example Co | Widgets Made in Leeds".
• Don't stuff keywords, write in all caps, or add "Best" or "No. 1" claims you can't back up.

Examples:

Meta descriptions

Pattern: what the page offers, one concrete detail, and what the reader can do next.

Rules:

• Unique on every page that matters. If you can't write a good one for a page (thousands of products), a template that pulls in real details beats a generic sentence repeated everywhere.
• Concrete over clever. Prices, sizes, delivery times, number of steps, who it's for.
• Write for the person, not the crawler. The description isn't a ranking factor; it is an advert for the click.
• End with a reason to click, without shouting: "See sizes and delivery options."
• Avoid double quotes inside the description. Some systems cut the text at the first quote. Use single quotes.
• No false claims. A description that over-promises gets the click and then the bounce.

Examples:

Share titles and descriptions

Share cards are read in a feed, next to a friend's name, not in a list of search results. They can be warmer than search titles.

• Drop the site name from og:title. The card shows your domain.
• Use the description to say why it's worth opening now.
• Check how it looks with the image: the three pieces should work together, not repeat each other.

Process for a whole site

1. Export every URL with its current title and description (most crawlers and SEO tools can do this, or use Search Console's page list).
2. Sort by traffic or importance. Fix the top 20 pages by hand first.
3. Find duplicates and empties, and fix them with better templates.
4. Re-check in Search Console after a few weeks: compare click-through rate before and after for the pages you changed.

Quick checklist

• Every indexable page has a unique <title> of roughly 50 to 60 characters.
• The most important words appear in the first 40 characters of the title.
• Every important page has a unique meta description of roughly 120 to 155 characters.
• Descriptions include a concrete detail and match the page content.
• No double quotes inside descriptions.
• Share titles and descriptions are set for pages people share.
• Templates fall back to sensible values, never to blank or "Untitled".

robots.txt: the default and its variants

robots.txt lives at the root of your domain (https://example.com/robots.txt) and tells crawlers which paths they may fetch. Each subdomain needs its own file.

Two things it does not do:

• It doesn't hide pages from search results. A blocked page can still be listed, with no description, if other sites link to it. To keep a page out of results, let crawlers fetch it and use <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header.
• It isn't security. The file is public, and badly behaved bots ignore it. Never list a secret admin path you rely on nobody finding. Protect private areas with a login.

The default in this folder

User-agent: *
Disallow: /admin/
Disallow: /account/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?

Sitemap: https://example.com/sitemap.xml

What each line is for:

Change the paths to match your site, and delete any you don't have. Rules are prefix matches: Disallow: /cart/ blocks /cart/ and everything under it, but not /cartoons. A rule without the trailing slash, such as Disallow: /cart, would block /cartoons too.

Don't block what pages need to render

Search engines render pages like a browser. If you block your CSS, JavaScript, images or the API your pages call to fetch content, they see a broken page. Don't disallow /assets/, /static/, /_next/, /wp-content/ or similar.

Variant: allow everything

For a small site with nothing private, this is a fine robots.txt:

User-agent: *
Disallow:

Sitemap: https://example.com/sitemap.xml

An empty Disallow: means "nothing is blocked". Having no robots.txt at all has the same effect, but the file is a convenient place to list your sitemap.

Variant: staging or preview sites

Block all crawling on staging, and protect it with a password as well. robots.txt alone won't keep a staging site out of search if someone links to it.

User-agent: *
Disallow: /

Add X-Robots-Tag: noindex to every response on staging too. The biggest risk is copying this file to production by accident. Generate robots.txt per environment in your build, and check the live file on launch day.

Variant: block URL parameters

Faceted navigation (filters, sorting, tracking parameters) can create thousands of duplicate URLs. Google and Bing support * as a wildcard and $ for the end of a URL:

User-agent: *
Disallow: /*?*sort=
Disallow: /*?*sessionid=
Disallow: /*.pdf$

The first two block any URL with that parameter, in any position. The last blocks every URL ending in .pdf. Use these carefully: one wrong wildcard can block your whole catalogue. Prefer canonical tags for duplicate pages you still want crawled.

Variant: opt out of AI training crawlers

Some companies use separate crawlers, or separate user-agent tokens, to collect content for training AI models. You can block those while still allowing normal search crawling:

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Notes:

• Google-Extended and Applebot-Extended are control tokens, not separate crawlers. Blocking them doesn't affect Google Search or Apple's search features.
• Each AI company publishes the user-agent names it uses. The list changes often, so check each company's crawler documentation and update this group a few times a year.
• Blocking is a request, not enforcement. Respectful crawlers follow it.
• Blocking an assistant's live-browsing agent may stop that assistant from citing or linking to your pages. Decide what you want for each.

Variant: slow down a specific crawler

User-agent: [Crawler name]
Crawl-delay: 10

Bing and some others respect Crawl-delay (seconds between requests). Google ignores it; Google adjusts its crawl rate automatically based on how your server responds.

Rules about groups

• A crawler uses only the most specific group that names it, and ignores the * group. If you add a group for one crawler, repeat any general rules it should also follow.
• When Allow and Disallow both match, Google uses the longest (most specific) rule.
• Paths are case-sensitive.
• The file must be plain text, UTF-8, served with status 200. A 5xx error on robots.txt can make Google pause crawling your whole site.

Check it

• Fetch https://example.com/robots.txt in a browser and read what is actually live.
• Use the robots.txt report in Google Search Console to see the version Google has and any parsing errors.
• Test a few important URLs to confirm they are allowed.

Sitemap guide

A sitemap is a list of the URLs you want search engines to find. It doesn't force anything into the index, but it helps crawlers discover new and updated pages faster, especially on new sites with few links pointing to them.

The two files in this folder

Both use the standard sitemaps.org format, which Google, Bing and other engines read.

What goes in

Include a URL only if all of these are true:

• It returns status 200 (not a redirect, not a 404).
• It is the canonical version (its <link rel="canonical"> points to itself).
• It isn't noindex.
• It isn't blocked by robots.txt.
• You'd be happy for someone to land on it from search.

Leave out: redirects, paginated filter combinations, internal search results, thank-you pages, login pages, staging URLs and URLs with tracking parameters.

The tags

Keep lastmod honest. Set it when the main content changes, not on every build or when a footer link changes. Search engines learn to ignore lastmod on sites where it always says "today".

Extensions shown in the example

• Images (image:image): lists important images on a page. Useful for image-heavy pages whose images load by JavaScript. Most sites don't need it.
• Language alternates (xhtml:link): an alternative to hreflang tags in the HTML. Each language version lists every version, including itself, plus x-default. Use one method, not both, so they can't disagree.

Escaping

URLs in a sitemap must be XML-escaped. The most common mistake is a raw & in a query string:

Non-ASCII characters in paths should be percent-encoded, for example https://example.com/caf%C3%A9.

Where to put it and how to tell search engines

1. Serve it at a stable URL, usually https://example.com/sitemap.xml. A sitemap can only list URLs on its own host and below its own folder, unless you submit it through Search Console for the whole property.
2. Add a Sitemap: line with the full URL to robots.txt.
3. Submit it in Google Search Console (Indexing, Sitemaps) and Bing Webmaster Tools (Sitemaps). See launch-indexing-checklist.md.
4. Serve it with Content-Type: application/xml or text/xml and status 200.

You can also gzip a sitemap (sitemap.xml.gz). The 50 MB limit applies to the uncompressed size.

Generate it, don't hand-write it

For anything beyond a handful of pages, generate the sitemap from your routes or CMS on each build or on request. Most frameworks and CMSs have a plugin or built-in option. Hand-written sitemaps go stale within weeks.

Whatever generates it, check:

• It uses the production domain, not localhost or a preview URL.
• It drops pages that were deleted or set to noindex.
• lastmod comes from the content's real modified date.
• It doesn't include every tag, author and archive page unless those pages are useful on their own.

Check it

• Open the URL in a browser. It should display as XML without errors.
• Validate it with an XML checker, or run python -c "import xml.dom.minidom,sys; xml.dom.minidom.parse(sys.argv[1])" sitemap.xml locally.
• After submitting, read the Sitemaps report in Search Console for errors, and compare "discovered" URLs with what you expect.
• Spot-check five URLs from the sitemap: each should return 200, be canonical and be indexable.

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

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.