Keep a category archive crawlable when it is a useful destination in its own right. Treat sort-only versions and unnecessary filter combinations as variations—not more category pages. Start by listing the URL patterns your blog actually serves, then choose a treatment that preserves individual article URLs. Google warns that parameter-based filters can generate very large URL spaces and recommends preventing crawling of faceted URLs that do not need to appear in Search.
Inventory the archive before changing crawl rules
Ask your developer for examples of the unfiltered archive, each category view, sort-only views, category-plus-sort views, and individual article pages. For each pattern, record its URL, what it displays, whether visitors need the variation, and whether you want that exact URL to be a search destination. Check both parameter orders if the site accepts them. This prevents a broad rule aimed at archive filters from accidentally catching article routes.
Judge category views by their usefulness, not by the presence of a parameter. A category with a distinct collection that visitors intentionally browse may deserve its own crawlable URL. A second URL that only rearranges the same collection usually does not need to be another search destination. Confirm that wanted categories and articles remain reachable without relying on a blocked filter URL; Google’s faceted-navigation guidance specifically distinguishes restricting filtered listings from allowing crawlers to reach individual item pages.
Decide which variations stay available to crawlers
Consider a fictional SaaS archive with /blog as its main listing, /blog?category=security as a useful security category, and /blog?category=security&sort=newest as that same category reordered for readers. The spaces inside these code examples are only for readability; the live URLs would have none. The resulting choice: leave the main archive and security category crawlable, keep the newest-sort control usable for visitors, and restrict crawling of archive URLs containing sort. Also cover /blog?sort=newest&category=security if the site accepts that order. Keep an article such as /blog/secure-access-guide outside the archive-filter rule.
That choice fits a sort control people use but that does not need a separate search destination. Google recommends robots.txt restrictions when faceted URLs need not appear in Search, while allowing access to individual detail pages. A robots.txt block controls crawling; do not present it as a guaranteed way to remove a URL already appearing in search results.
Choose a different treatment if the inputs differ. If nobody needs a sort URL, a permanent redirect to its appropriate unfiltered or category URL removes that variation for visitors too. If the sorted view must remain crawlable and is substantially similar to the category view, a rel="canonical" pointing to that category expresses a preference, not a guarantee that Google will choose it. Canonical annotations may reduce crawling of faceted variants over time, but Google describes them as generally less effective at preventing crawling than robots.txt restrictions. Do not rely on a canonical tag inside a URL you have blocked from crawling.
Give the developer a pattern-level fix request
For the fictional archive, send this request: “Keep /blog and approved /blog?category=… pages crawlable. Keep the newest-sort feature working for visitors, but add a robots.txt restriction for archive requests containing the sort parameter, whether it is first or follows category. Scope the rule to archive requests; do not block /blog/secure-access-guide or other article paths. Make sure each approved category has a crawlable route that does not depend on a sorted URL. Show me how both parameter orders, a category-only URL, the main archive, and an article URL behave after release.” Remove the illustrative spaces and replace these routes with the site’s actual patterns before implementation.
Have the developer inspect existing rules before adding this one: a general restriction on category could defeat the decision to keep selected categories crawlable. If a category does not merit its own destination, specify its actual alternative rather than automatically pointing every category at the main archive. Ranks says its articles live on the customer’s own blog; these archive routing and robots.txt decisions therefore belong to the website owner and developer, not to the article draft.
Check the public URLs after release
Test the live main archive, an approved category, both sorted parameter orders, and an article page. Confirm the first two and the article still serve their intended content; confirm both sorted URLs still work for visitors and match the intended robots.txt restriction. Check an unapproved category or other combination separately if it has a different intended treatment. A passing test of one query-string order does not establish that the other order is covered.
If you use canonical annotations instead of a crawl restriction, inspect representative live pages for the stated canonical and use Search Console’s URL Inspection tool to compare it with Google’s selected canonical. If an existing URL must be removed from Search, do not combine a robots.txt block with noindex: Google says a blocked crawler cannot see that directive. Keep that removal decision separate from the crawl-saving rule above.
This fix is about duplicate archive routes, not whether older posts have a link path through the archive. If that is the failure you find while testing, use the separate guide to making older SaaS posts discoverable.
