[P0] Audit: All Tools filter and search parameter URLs may be indexable

[baixiangcpp]

Imported from the byteflow.tools deep audit on 2026-06-22.

Problem: the All Tools page supports search and filters. If filter states create crawlable query URLs, the site can generate many thin or duplicate pages.

Affected URL patterns:

• https://byteflow.tools/en/all-tools?search=...
• https://byteflow.tools/en/all-tools?category=...
• https://byteflow.tools/en/all-tools?execution=...
• https://byteflow.tools/en/all-tools?tag=...

Reproduction steps:

1. Open /en/all-tools.
2. Use search, category, execution, input type, use-case, and tag filters.
3. Check whether the URL changes to include query parameters.
4. Open the generated URL in a fresh session.
5. Inspect canonical and robots meta tags.
6. Confirm whether parameter URLs appear in sitemap.

Expected behavior: only the clean /en/all-tools hub should be indexable. Filtered states should be noindex/follow or canonicalized to the clean URL unless a curated landing page exists.

Actual behavior: robots.txt only blocks handoff parameters, and there is no clear guard for all-tools filter/search parameters.

Impact: crawl budget waste, duplicate indexation, low-quality parameter pages, and weaker canonical signals.

Proposed fix:

• Add self-canonical to clean /en/all-tools.
• Add noindex,follow or canonical-to-clean behavior for query-parameter pages.
• Exclude parameter URLs from sitemap.
• Keep filters in client state where possible.
• Create only manually curated landing pages for high-value filters.

Acceptance criteria:

• /en/all-tools is indexable and canonical to itself.
• /en/all-tools?... pages are noindexed or canonicalized.
• Sitemap contains no filter/search parameter URLs.
• Search Console shows no parameter URL growth.

[baixiangcpp]

Closed as completed by the canonical BF audit backlog work. This older non-BF audit issue duplicates work now merged through PRs #209-#219, with the BF issues closed and guard/test coverage in place. The remaining non-duplicate follow-up is #7, which stays open because the upstream Next/PostCSS advisory is not fixed yet.