Free Search Results Page Schema Generator

What is SearchResultsPage structured data?

SearchResultsPage identifies pages generated by an internal search query on your site (e.g., /search?q=jackets). It complements WebSite + SearchAction so search engines understand your site-search experience, distinguish it from category pages, and consider showing a sitelinks search box.

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

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://www.example.com/",
  "name": "Example",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

On the search page:

{
  "@context": "https://schema.org",
  "@type": "SearchResultsPage",
  "name": "Search results for “espresso beans”",
  "url": "https://www.example.com/search?q=espresso%20beans",
  "isPartOf": {
    "@type": "WebSite",
    "name": "Example",
    "url": "https://www.example.com/"
  },
  "inLanguage": "en-US",
  "description": "Customer results for espresso beans with filters for roast and grind."
}

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.

{
  "@context": "https://schema.org",
  "@type": "SearchResultsPage",
  "name": "Search results for “nonfiction bestsellers”",
  "url": "https://www.example.com/search?q=nonfiction+bestsellers",
  "mainEntity": {
    "@type": "ItemList",
    "itemListOrder": "https://schema.org/ItemListUnordered",
    "itemListElement": [
      {
        "@type": "Book",
        "name": "The Decision Maker",
        "author": "Alex Hart",
        "url": "https://www.example.com/books/the-decision-maker"
      },
      {
        "@type": "Book",
        "name": "Signals",
        "author": "Priya N.",
        "url": "https://www.example.com/books/signals"
      }
    ]
  },
  "description": "Live results from our bookstore for nonfiction bestsellers.",
  "isPartOf": {
    "@type": "WebSite",
    "name": "Bright Books",
    "url": "https://www.example.com/"
  }
}

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.