JSON-LD schema for a UK SaaS in 2026: the Next.js builder's walkthrough

Your Next.js 16 SaaS is shipping without schema markup and it is quietly costing you money every single day. Rich results you are not eligible for. AI citations that land on the competitor who bothered to write sixty lines of JSON. Click-through rates a point or two below where they should be. Google can parse your HTML just fine, of course, but without JSON-LD it is guessing at what your page actually is - which string is the author, which block is the body, which page is the parent. And in 2026, with AI search engines weighing entity graphs heavier than ever, guessing is not good enough.

This is the walkthrough I wish I had when I first wired schema into an IdeaStack-style reports hub. No theory, no exhaustive schema.org tour, no "it depends" waffle. Just the five schemas every UK SaaS needs, the exact TypeScript to drop into Next.js 16 Server Components, the UK locale tweaks that actually move the needle, and the validation flow that catches errors before Search Console does. You could ship this in an afternoon. Several afternoons if you are pedantic about commit messages. The point is: this is a one-sitting job, not a quarter-long project.

What JSON-LD actually does in 2026

JSON-LD is a JSON-shaped blob of structured data you drop into your HTML inside a <script type="application/ld+json"> tag. Crawlers read it and build an entity graph: "this page is an Article, written by this Person, published by this Organization, which is part of this WebSite." It does three things that matter right now.

First, rich results eligibility. FAQ accordions, breadcrumb trails, article cards with author and date, sitelinks search boxes - all of those require valid schema. No schema, no rich result, flat blue links only. Second, AI citation probability. ChatGPT search, Perplexity, Claude with web, Google AI Overviews - they all weight structured data when deciding who to quote. A clean entity graph with linked sameAs and @id references is easier to cite than a wall of text. Third, the classic entity graph benefit: Google learns who you are as a business, links your brand to your founders and your products, and starts treating your domain as a trusted source rather than a random Next.js deployment on Vercel.

That is the entire pitch. Ninety percent of indie SaaS never ship schema. The ones that do pull ahead. Let's get you into the ten percent.

The five schemas every UK SaaS needs

Forget the long tail of schema types for a moment. There are exactly five you need to ship before you worry about Recipe, Event, or HowTo. Learn these, get them validated, revisit the rest when you have a specific need.

Organization. Your business as an entity. Legal name, trading name, logo URL, UK address, contact points, sameAs links to your Twitter, LinkedIn, GitHub. Goes in the root layout so every page carries it. This is how Google knows your brand exists as a thing and links your mentions across the web back to one canonical entity.

WebSite. Your site as a whole. Includes a SearchAction potentialAction so Google may render a sitelinks search box under your homepage result. Also goes in root layout. Tiny schema, surprisingly impactful.

Article. Blog posts only. Headline, author, datePublished, dateModified, image, publisher reference back to your Organization. This is what makes your article eligible for the rich article cards in search results.

BreadcrumbList. Every non-home page. Shows the crumb trail in SERPs instead of a raw URL. Costs about fifteen lines of JSON per page and measurably improves click-through rate on deeper pages.

ItemList. Listing pages only - your reports hub, your pricing tiers, your changelog index. Tells Google "this page is a list of N things" and unlocks carousel-style rich results for category pages.

That is the whole kit. Five schemas. You can ship all five in an afternoon, validate in twenty minutes, and move on with your life.

Next.js 16 TypeScript walkthrough

Right, the code. The pattern is the same every time: build a typed JavaScript object that represents the schema, stringify it, drop it into a script tag inside a Server Component with dangerouslySetInnerHTML. The dangerouslySetInnerHTML prop name is alarming but this is the one legitimate use case - you want the JSON literal in the HTML output, not escaped. React has no other way to render an unescaped script body, so this is the pattern Google itself recommends.

Organization schema in the root layout

Drop this in app/layout.tsx. It will render on every single page on your site, which is exactly what you want.

// app/layout.tsx
import type { ReactNode } from "react";

const organizationSchema = {
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yoursaas.co.uk/#organization",
  name: "Your SaaS Ltd",
  alternateName: "YourSaaS",
  url: "https://yoursaas.co.uk",
  logo: {
    "@type": "ImageObject",
    url: "https://yoursaas.co.uk/logo.png",
    width: 512,
    height: 512,
  },
  sameAs: [
    "https://twitter.com/yoursaas",
    "https://www.linkedin.com/company/yoursaas",
    "https://github.com/yoursaas",
  ],
  address: {
    "@type": "PostalAddress",
    addressCountry: "GB",
    addressLocality: "London",
    addressRegion: "England",
  },
  contactPoint: {
    "@type": "ContactPoint",
    contactType: "customer support",
    email: "hello@yoursaas.co.uk",
    areaServed: "GB",
    availableLanguage: ["English"],
  },
};

export default function RootLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en-GB">
      <head>
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{
            __html: JSON.stringify(organizationSchema),
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

A few things to note. The @id is a canonical identifier for your Organization entity - always the same URL with a hash fragment like #organization. Other schemas will reference this @id to say "this article is published by that organization." The html lang="en-GB" attribute is quietly important: it tells the browser and all crawlers your language is UK English, not US English, which matters for localised search results.

WebSite schema with SearchAction

Same layout file, second schema. You can either add a second script tag or wrap both in an @graph. I prefer two separate tags - easier to debug when one fails validation.

const websiteSchema = {
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://yoursaas.co.uk/#website",
  url: "https://yoursaas.co.uk",
  name: "Your SaaS",
  description: "UK SaaS that does the thing",
  inLanguage: "en-GB",
  publisher: {
    "@id": "https://yoursaas.co.uk/#organization",
  },
  potentialAction: {
    "@type": "SearchAction",
    target: {
      "@type": "EntryPoint",
      urlTemplate: "https://yoursaas.co.uk/search?q={search_term_string}",
    },
    "query-input": "required name=search_term_string",
  },
};

The potentialAction is what unlocks the sitelinks search box. You need an actual /search page at that URL that accepts the q query parameter and returns results - Google does check. If you do not have site search yet, omit the potentialAction entirely rather than pointing at a 404. The publisher field uses @id to reference the Organization you defined in the first schema, which is how Google links the two entities together into one graph.

BreadcrumbList via a helper

Breadcrumbs change on every page, so the cleanest approach is a small helper that builds the schema from an array of crumb objects. Put it in lib/schema.ts.

// lib/schema.ts
export type Crumb = { name: string; href: string };

export function buildBreadcrumbSchema(crumbs: Crumb[]) {
  return {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    itemListElement: crumbs.map((crumb, index) => ({
      "@type": "ListItem",
      position: index + 1,
      name: crumb.name,
      item: `https://yoursaas.co.uk${crumb.href}`,
    })),
  };
}

Then in any page:

// app/reports/[slug]/page.tsx
import { buildBreadcrumbSchema } from "@/lib/schema";

export default async function ReportPage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const report = await getReport(slug);

  const breadcrumbSchema = buildBreadcrumbSchema([
    { name: "Home", href: "/" },
    { name: "Reports", href: "/reports" },
    { name: report.title, href: `/reports/${slug}` },
  ]);

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbSchema) }}
      />
      <article>{/* your report content */}</article>
    </>
  );
}

The position starts at 1, not 0. The final crumb points to the current page's own URL. Breadcrumb items should be absolute URLs, not relative paths - a very common mistake that Google silently ignores rather than flagging loudly.

Article schema on a blog post

The big one. Goes inside your individual blog post page file.

// app/blog/[slug]/page.tsx
import { buildBreadcrumbSchema } from "@/lib/schema";

export default async function BlogPostPage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const post = await getBlogPost(slug);

  const articleSchema = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: post.title,
    description: post.excerpt,
    image: [
      `https://yoursaas.co.uk${post.ogImage}`,
    ],
    datePublished: post.publishedAt,
    dateModified: post.updatedAt ?? post.publishedAt,
    inLanguage: "en-GB",
    author: {
      "@type": "Person",
      name: post.author.name,
      url: `https://yoursaas.co.uk/authors/${post.author.slug}`,
    },
    publisher: {
      "@id": "https://yoursaas.co.uk/#organization",
    },
    mainEntityOfPage: {
      "@type": "WebPage",
      "@id": `https://yoursaas.co.uk/blog/${slug}`,
    },
  };

  const breadcrumbSchema = buildBreadcrumbSchema([
    { name: "Home", href: "/" },
    { name: "Blog", href: "/blog" },
    { name: post.title, href: `/blog/${slug}` },
  ]);

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(articleSchema) }}
      />
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbSchema) }}
      />
      <article>{/* post body */}</article>
    </>
  );
}

A few non-obvious requirements. datePublished and dateModified must be ISO 8601 strings, including the time and timezone (2026-04-23T09:00:00+01:00). A date-only value like 2026-04-23 technically validates but Google prefers the full form. image must be an array, even if you have only one image, and the image URL must be absolute. The mainEntityOfPage field is what tells Google "this Article is the primary content of the page at this URL" - without it, some rich result variants do not render.

ItemList on a reports hub page

If you have a listing page - reports, case studies, tutorials - add ItemList so Google understands the page is a collection. Example for a reports hub like the one IdeaStack runs:

// app/reports/page.tsx
export default async function ReportsHub() {
  const reports = await getLatestReports(20);

  const itemListSchema = {
    "@context": "https://schema.org",
    "@type": "ItemList",
    name: "UK business idea reports",
    description: "Weekly data-backed reports on UK business opportunities",
    itemListOrder: "https://schema.org/ItemListOrderDescending",
    numberOfItems: reports.length,
    itemListElement: reports.map((report, index) => ({
      "@type": "ListItem",
      position: index + 1,
      url: `https://yoursaas.co.uk/reports/${report.slug}`,
      name: report.title,
    })),
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(itemListSchema) }}
      />
      <main>{/* render the hub */}</main>
    </>
  );
}

You can go deeper by replacing each ListItem with a full Article nested node, but the lightweight version above is enough for Google to understand the page and render carousel-style results where appropriate. Ship the light version first, iterate if you need more.

UK-specific tweaks that actually matter

Three quiet details separate a UK-focused SaaS from a site that Google mistakes for a US product.

inLanguage. Set inLanguage: "en-GB" on WebSite and Article. Not en, not en-US. This is the single biggest signal to Google that you are a UK publisher, and it influences which country's SERP you rank in.

addressCountry and areaServed. On your Organization schema, set addressCountry: "GB" inside the PostalAddress. If you only trade in the UK, add areaServed: "GB" to the organization root or your contactPoint. If you trade internationally, use an array: areaServed: ["GB", "IE", "US"]. This helps local pack results and map-based queries.

priceCurrency GBP. Any time you have an Offer node - pricing tiers, product prices, subscription plans - priceCurrency must be the ISO 4217 three-letter code GBP. Not the symbol. Not "British Pounds". Not "UK Pounds". GBP. A typical pricing node looks like:

const offerSchema = {
  "@type": "Offer",
  price: "12.00",
  priceCurrency: "GBP",
  availability: "https://schema.org/InStock",
  url: "https://yoursaas.co.uk/pricing",
};

That is £12/mo in schema-land. Get this wrong and Google may render your price in dollars for US searchers - which looks careless and kills conversion.

How to validate before you ship

Two validators. Use both, in this order.

Google Rich Results Test at search.google.com/test/rich-results. Paste your deployed URL, hit Test URL, wait ten seconds. It tells you which rich result types you are eligible for and flags blocking errors in red. This is the validator that actually matters for ranking - it mirrors what Googlebot sees when it crawls your page.

Schema.org validator at validator.schema.org. Paste your URL or your JSON-LD directly. This catches structural issues that Google's tool skims over - missing required properties, wrong types, malformed @id references. Warnings from this tool are fine to ignore if the Google one is happy, but errors are worth fixing.

Which errors actually matter and which are noise? Errors that block rich result eligibility (missing headline, invalid datePublished, image is not an ImageObject or URL) are worth fixing right now. Warnings like "recommended property 'wordCount' is missing" are optional - Google is saying "it would be nicer if you added this," not "you are broken." Fix errors, ignore recommendations unless you are specifically chasing a rich result variant that needs them.

Run both validators on a fresh deploy, then again after any content model change - if you update your CMS schema, rename a field, change your URL structure. Catching a broken @id in staging is free; catching it in Search Console two weeks later after your rich results have disappeared is a bad Thursday.

Five common builder mistakes

Real mistakes that real builders make, in rough order of frequency.

Wrong @context URL. It is https://schema.org, with https, no trailing slash. Not http://schema.org, not https://www.schema.org, not schema.org. Crawlers will usually follow the redirect if you get it wrong, but some validators do not. Copy the exact string.

Invalid or inconsistent @id. @id should be a canonical URL for the entity, used consistently across every schema on every page. If your Organization @id is https://yoursaas.co.uk/#organization in the root layout, it must be exactly that in your Article's publisher reference. Different casing, a missing slash, a www that appears on one page and not another - Google treats these as separate entities and your graph fragments.

Missing required properties on Article. headline, datePublished, author, publisher, image are all required. Miss any one and the Article schema silently fails to qualify for rich results even if everything else is perfect. Add them all even if you think the value is boring.

Breadcrumbs pointing to wrong URLs. The item field on each ListItem must be the absolute URL for that page. Relative paths, trailing slashes that do not match your canonical URLs, or pointing a middle crumb at a URL that 404s - all silent failures. Build your breadcrumb items from the same URL source your canonicals use.

Duplicating schemas across nested components. If your layout renders Organization schema and your page component also renders Organization schema, you now have two Organization nodes with the same @id. Google may dedupe or may get confused. Pick one location per schema type and stick to it: Organization and WebSite in root layout, everything else in the page file. Never in both.

The 30-minute ship-it checklist

Set a timer. Half an hour. You can do this.

1. Open app/layout.tsx. Paste the Organization schema with your real legal name, logo URL, UK address and sameAs links. Two minutes.
2. Paste the WebSite schema underneath with your description, en-GB, and a SearchAction pointing at your /search page (or omit potentialAction if no search exists). Two minutes.
3. Create lib/schema.ts with the buildBreadcrumbSchema helper from above. Two minutes.
4. Open your main page template (blog post, report, landing page). Add the Article schema and call buildBreadcrumbSchema with real crumbs. Five minutes.
5. Open your listing hub page. Add the ItemList schema with the slugs and titles of the latest items. Five minutes.
6. Deploy to a preview URL on Vercel. Wait for the build. Two minutes.
7. Paste the preview URL into Google Rich Results Test. Read the output, fix anything red. Five minutes.
8. Paste the URL into schema.org validator. Fix any structural errors, ignore warnings. Three minutes.
9. Merge to main. Deploy to production. Four minutes.

Thirty minutes, give or take a coffee. You are now in the ten percent of indie SaaS that ships real schema.

Key takeaways

JSON-LD is the cheapest SEO win left in 2026. Five schemas - Organization, WebSite, Article, BreadcrumbList, ItemList - cover almost every surface of a UK SaaS. Render them from Server Components using script tags with dangerouslySetInnerHTML so crawlers see them in the initial HTML. Get the UK locale details right: en-GB, GB, GBP. Validate with both Google's tool and schema.org before and after every deploy.

If you want a primer on the measurement side before you ship more content, start with our UK SaaS analytics stack under £50/mo guide. And if you are still figuring out whether the idea behind your SaaS is even worth the schema effort, the seven-day validation framework in how to validate a UK SaaS idea in 7 days is where to start.

Schema does not replace content. It makes your content legible to the algorithms that decide who gets seen in 2026. Ship the five, validate, move on.

---

This week's free report: UK Charity Soft Opt-In Compliance Toolkit

Score: 8.0/10 — read the full breakdown

Every Thursday we publish a new data-backed UK business opportunity. Subscribe free to get it in your inbox.