SwiftSchema

What is SearchResultsPage structured data?

SearchResultsPage identifies pages generated by an internal search query on your site (e.g.,

Use it when:

• The URL is clearly an internal search results page (query parameter or clean
  /search/
  path).
• Results change based on user-entered terms.
• The page is indexable and returns meaningful results (not empty).

Avoid it when:

• The page is a curated category/collection (use CollectionPage + ItemList instead).
• The page is blocked by
  noindex
  or robots.txt (schema won’t be seen).
• Results are empty or error-like (fix UX first).

Eligibility & status

SearchResultsPage is a contextual type (“not direct”) — it does not create its own rich result. Its job is to clarify purpose and support features tied to WebSite + SearchAction (sitelinks search box) and better understanding of query-driven pages. Correct pairing and clean UX are what move the needle.

What good looks like (content + UX)

• A visible, descriptive H1 like “Search results for ‘espresso beans’”.
• Canonical URL that matches the search page (avoid pointing to the homepage).
• Useful results with pagination, filters, and “no results” messaging that suggests alternatives.
• Internal links back to hubs/categories, plus recent searches or popular queries.
• Fast, indexable page without interstitials or blocked resources.

Required and recommended properties

• name
  (required): Use a dynamic string that reflects the query (e.g., “Search results for ‘jackets’”).
• url
  (required): Canonical search URL, including the query parameter or path.
• description
  (recommended): Short summary of the intent (“Customer results for espresso beans filtered by roast and grind.”).
• inLanguage
  (recommended): Locale such as
  en-US
  .
• isPartOf
  (recommended): Reference your WebSite (
  name
  +
  url
  ).
• potentialAction
  (recommended): Include
  SearchAction
  on the WebSite entity so engines know how to query your site.
• mainEntity
  (situational): If you render a stable list, wrap it in ItemList with Products/Articles/etc. Use when results are meaningful and not empty.

Implementation workflow (SwiftSchema)

1. Choose SearchResultsPage in the generator.
2. Add a descriptive
   name
   that mirrors the visible H1.
3. Paste the canonical search URL (include query parameters).
4. Add
   description
   and
   inLanguage
   if relevant.
5. Link back to your WebSite via
   isPartOf
   .
6. Ensure your root WebSite JSON-LD includes
   SearchAction
   .
7. If results are consistent and meaningful, add an ItemList with top results.
8. Copy JSON-LD or script, paste into the search template, and validate.

Example: paired with WebSite + SearchAction

On the search page:

Example: search results with ItemList (product scenario)

Use when you render stable, meaningful results and can expose a few top items. Do not include empty results or placeholder items.

Page-quality checklist

• H1: “Search results for ‘<query>’” (matches
  name
  ).
• Canonical: self-referential; do not canonicalize to home.
• Results: not empty; show pagination counts and filters.
• UI: visible breadcrumbs or nav back to hubs/categories.
• Speed: keep LCP < 2.5s; avoid heavy client-side only rendering for core content.
• Accessibility: announce result counts; focus states on filters; keyboard-friendly pagination.

Common mistakes to avoid

• Marking categories as SearchResultsPage. Use CollectionPage + ItemList for curated lists.
• No SearchAction on WebSite. Without it, sitelinks search box is unlikely.
• Blocking the page. Robots.txt disallow or meta noindex makes the schema unusable.
• Empty or error states. Provide a “no results” experience with suggested links; avoid serving schema for error pages.
• Mismatched URLs. The
  url
  in JSON-LD should match the canonical URL and user-visible query.
• Missing language. Add
  inLanguage
  if you localize results or operate in multiple locales.

Troubleshooting and validation

• Rich Results Test: Paste the rendered HTML of a search page to confirm SearchResultsPage + WebSite are detected.
• URL Inspection: Ensure the page is indexable (no blocked resources, proper canonical).
• Check query templating: If you change search URL patterns, update both the SearchAction target and the SearchResultsPage URLs.
• Monitor sitelinks search box: In Search Console, watch Enhancements → Sitelinks search box for errors/warnings.

Internal linking and discovery

• Link from nav/footer to “Search” so crawlers can discover it.
• Link from empty-result states to key categories or top searches.
• From learn/help pages, link to the search experience when relevant (“Search our patterns”).
• Surface popular queries on the search page to keep it useful even without a user query.

Maintenance routine

• Review quarterly or when search UX changes (new filters, paths, or domains).
• Keep
  lastReviewed
  fresh after significant template changes.
• If you add new languages, update
  inLanguage
  and ensure locale-specific URLs.
• Retest after deploys that touch routing or search components.