Create a search landing for one useful filter
Applies to the 0.8.1-dev development preview. Test on staging before production use.
Create an enabled Product Filters set first. Choose a category boundary and sources appropriate to the collection; verify its products in preview.
- In WordPress Pages, create a page with a useful heading, original explanatory content and a readable slug, for example
/plum-studio-clothing/. - Add exactly one Shortcode block containing
[hs_product_filters]. Save the page as a draft while preparing it. - Open HookSpark → Product Filters → SEO landing pages. Select the page, the enabled set and one filter value.
- Write its SEO title and description. The 200/500 character limits are storage/editor limits, not recommended snippet lengths or guarantees of Google's display.
- Keep the indexing switch off during preparation. Save and inspect the page. Use WordPress's page editor to change the heading, body, URL or publication status.
- Request indexing only when the collection has products and useful, distinct content. Publish through WordPress when ready. Link the page from relevant navigation or editorial content.
Saving SEO settings does not publish the page. WordPress resolves duplicate page slugs using its native rules; always inspect the final saved URL. A second opted-in landing for the same set/term is rejected. Distinct set definitions can still overlap: review their content instead of relying on automatic semantic deduplication.
What each state means
| State | Index policy | Metadata |
|---|---|---|
| Exact single-filter landing, switch off | noindex | Authored title/description remain useful for preview |
| Exact nonempty landing, switch on | Eligible only if site/provider permit it | Authored title/description, native page canonical when not suppressed |
| Added size, material, price, stock, sorting, multiple values or page number | noindex | Generic browsing title; no inherited description; no misleading base canonical |
| Invalid filter, impossible combination or nonexistent page | 404 plus noindex | Recovery controls remain usable |
| Catalog service failure | 503 plus noindex | Retry message |
Noindex is not a crawling block. Do not disallow a URL in robots.txt if you need a crawler to read its noindex directive. The plugin never changes robots.txt or WordPress's site visibility. Search engines decide when to recrawl and whether to include an eligible page.
The native sitemap contains no arbitrary query combinations. Configured noindex, empty or unavailable landings are excluded. Rechecking candidates currently reads the native catalog and can be expensive on large stores; large-catalog optimization remains a release gate.
Editing and recovery
A rejected save retains input, shows field feedback and focuses the first invalid field. A concurrent change is rejected; compare the latest configuration before retrying. Trash or unpublish the native page through WordPress to remove it from public navigation; no automatic redirect to unrelated content is created. If a source or term is removed/renamed, review the binding and save the intended value again. Do not change URLs without planning redirects from existing inbound links.
The active-filter chips remove one selection while preserving the others and returning to page one. Removing the landing's own term broadens browsing and remains noindex. The catalog's Reset link restores the landing's original single filter. Back/Forward restores filters and document metadata together. Browser combinations remain parameter URLs; readable paths belong to explicitly created pages. A page with multiple Product Filters grids is not supported by this SEO binding.
Yoast SEO 28.5 and Rank Math 1.0.278 passed 84 HTTP assertions each on WordPress 7.1.1, WooCommerce 11.1.0 and PHP 8.2.29: exact and combined metadata, provider/site noindex, canonical behavior and actual XML sitemap updates. The minimum platform (WordPress 6.8 / WooCommerce 10.6.0 / PHP 8.2.29) passed 85 HTTP assertions each with Yoast 27.9 and Rank Math 1.0.278. Yoast 28.5 requires WordPress 6.9 or later. Other versions remain unverified. Other SEO plugins and themes that independently output metadata need verification; do not enable two full SEO plugins together. Existing noindex/nofollow restrictions are retained. Review actual HTML, headers and sitemap before enabling indexing on a production site.
The personal admin demo permits editing SEO settings only for its seeded pages. It intentionally does not grant general page creation/publication rights. A store administrator can create or edit the native pages on their own WordPress site.
While building a sitemap, pages using the same filter set share one native catalog scan. Only the configured landing terms are retained in request memory; nothing is cached between visitors. Product or filter changes invalidate these temporary counts. The first scan still reads the complete catalog, so large-store response time remains under optimization.
Preview before saving
Use Preview SEO impact to inspect the current draft URL, title, description, selected filter and matching count. It does not save a binding, publish a page or change the site's indexing settings. Review the preview, then use Save SEO settings deliberately.
An unpublished or password-protected page cannot qualify as a public landing. Empty results are reported as noindex with the public HTTP 404 policy. Indexing requested is conditional: site-wide and SEO-plugin restrictions still apply. Counts use your current preview context; visitor visibility can differ. Combined filters never inherit the authored metadata or permission.
If you edit any SEO field after generating the preview, it is hidden and a refresh message appears. Run Preview SEO impact again before reviewing the new values. Returning every field to the exact previewed values restores that preview.
Filter links normalize parameter and term order, duplicate selections, decimal spelling and default values. Exact SEO landings retain their readable URL. Broadening a landing retains an explicit filter request so its default term is not silently reapplied. Incoming invalid requests are left available for correction. This navigation normalization does not add index permission or change canonical/noindex policy.
Read the SEO impact checks
The preview separates Landing permission, Site visibility, and Canonical planned by Product Filters. A landing opt-out and WordPress discouraging search engines are independent reasons for noindex. A qualifying exact landing shows its native page URL as the planned canonical; a noindex state omits it. Page publication/password and empty-result explanations remain beside the result.
Crawling and external restrictions lists what the preview has not checked: robots.txt, server response headers, SEO-plugin overrides and actual indexing. Open robots.txt from the provided link to review its rules separately. The preview does not claim that a crawler can reach the URL. A canonical names a preferred URL; it does not grant indexing permission. A crawl block can prevent search engines from reading noindex. Verify the public response and search-engine inspection tools for those external conditions. No setting is rewritten automatically.
Resolve readable URL conflicts
Before saving SEO settings, the plugin checks the selected page slug with WordPress uniqueness rules. For a published page, its native permalink must also resolve back to that same page. A conflicting draft slug, a rewrite pointing elsewhere, or an unresolved published URL produces a page-field error and prevents saving the binding. Existing settings remain unchanged.
Change the slug in the native page editor, or repair the conflicting permalink/rewrite configuration, then preview again. The plugin does not rename pages, publish drafts or flush rewrite rules automatically. A draft without an assigned slug remains configurable; its final address must be checked after publication. These are native WordPress checks, not a crawl of redirects introduced by a proxy, web server or external service.