Faceted Nav SEO Case Study in Pakistan

The Client

The business was a mid-stage B2B SaaS company headquartered in Islamabad, selling a workflow and operations platform to mid-market teams across Pakistan, the Gulf, and the Pakistani diaspora running companies abroad. Their revenue mix leaned on outbound sales and paid acquisition — Google Ads for bottom-funnel brand-adjacent terms, and LinkedIn Ads for category awareness — both of which were covering customer acquisition cost comfortably. Organic, on paper, was a secondary channel, which is exactly why no one had been watching it closely.

Their marketing site was a custom Next.js build, fast and well-designed, structured around two commercial directories. The first was an integrations directory: roughly 180 pages, one per third-party tool their platform connected with (accounting software, CRMs, helpdesks, messaging apps, and so on). The second was a features directory of about 60 pages. Both directories were layered with multi-select faceted filters — by category, deployment type, pricing tier, team size, industry, and language — so that a prospect could, in theory, find exactly the integration they needed for their stack.

Over two years of shipping features and integrations quickly, those filters had quietly generated tens of thousands of URL combinations. Nobody owned SEO governance over URL creation, and the engineering team quite reasonably treated each filter state as a useful page. The result was a directory that was helpful for a logged-in user and near-invisible to Google.

The team had invested seriously in content and a clean design, and paid channels were doing their job. But organic growth had flatlined for three quarters. Their integration pages — which should have been their strongest commercial pages, capturing high-intent “[tool] + [platform]” searches — were barely ranking, while thinner competitor pages consistently outranked them. They engaged us for a focused technical SEO audit and implementation engagement to diagnose why their best pages had disappeared and to fix it.

The Problem

The diagnostic in the first two weeks surfaced a textbook faceted-navigation failure mode, amplified by a fast-shipping engineering team and no one owning URL governance. The symptoms were stark once we looked at logs instead of dashboards.

• A 250x duplication ratio. The integrations and features directories had ballooned to 61,200 indexable URLs generated from roughly 240 canonical pages. Every multi-select filter combination produced a new crawlable, indexable URL with near-identical content.
• Crawl budget haemorrhaging on junk. Server log analysis showed 47% of Googlebot’s daily fetches landing on parameterized duplicates that returned content more than 90% similar to the canonical page. Google was spending nearly half its crawl attention on pages that would never rank.
• Canonical pages not indexed. Of 1,140 canonical integration and feature pages, only around 560 were actually indexed. The rest sat in Google Search Console’s “crawled — currently not indexed” bucket, canonicalized away or orphaned.
• Authority flowing into dead ends. The top navigation and footer linked directly into filter URLs, passing internal authority into parameter pages that had no ranking value, instead of into the canonical integration pages where it was needed.
• No governance rules at all. There were no canonical tags on filter combinations, no consistent robots.txt parameter handling, and no noindex directives. Google was left to guess which of 50 near-identical URLs was the real one, and it guessed poorly.

The deeper issue was strategic, not just technical. The team had assumed that publishing more integration pages would grow organic traffic. In reality, every new filter combination was diluting the authority of the pages that already existed. They were not losing rankings because of thin content — they were losing rankings because Google could not tell which page to rank.

Phase 1 — Diagnosis and crawl mapping (Weeks 1-2)

We started with ground truth rather than tools. We pulled twelve months of raw server logs into BigQuery and parsed every Googlebot fetch, categorising each URL as canonical, parameter-duplicate, pagination, or orphan. In parallel, we ran a full Screaming Frog crawl (configured to follow the same filter paths Googlebot was hitting) and exported Google Search Console coverage data for the two directories.

This produced a single map: for every canonical page, how many duplicate variants existed, how often each was crawled, and which ones carried internal links. The map drove every later decision. The key finding was that a small number of filter parameters — team_size, language, and pricing_tier — were responsible for the majority of the duplication, while the filters with genuine search demand (category and deployment) were being treated identically and starved.

Diagnostic dimension	Finding
Indexable URLs across both directories	61,200
Canonical pages intended to rank	1,140
Duplication ratio	~54x average, 250x at peak
Googlebot fetches on duplicates	47% of daily crawl
Canonical pages indexed	~560 of 1,140 (49%)
Internal links into filter URLs	3,100+ from nav and footer

We also benchmarked the competition: for the 40 highest-value integration keywords, the average ranking page from competitors had fewer than five internal duplicates competing with it. Our client’s equivalent canonical page had, on average, 38. The gap was not content quality — it was self-cannibalisation.

A second pass of the data told us where to spend the authority we were about to reclaim. We crossed two signals for every canonical page: the organic impressions it already received (proof Google saw demand for it) and the keyword difficulty of its head term. Pages with healthy impressions but poor rankings — meaning Google recognised the demand and was choosing not to rank the page — went to the top of the prioritisation queue. Those were the clearest cases where architecture, not content, was the binding constraint, and they were the pages most likely to reward the rebuild quickly.

Phase 2 — URL architecture rebuild (Weeks 3-5)

With the map in hand, the rebuild was a sequence of governance decisions, each implemented as code so it could not regress. The guiding principle was simple: a filter combination is only indexable if it maps to a distinct search intent that a real prospect types into Google.

Classify every facet. We split the six filters into two sets. category and deployment_type became indexable facets — the only combinations allowed to generate crawlable URLs, because each maps to a distinct commercial query cluster (for example, “accounting integrations for [platform]” or “cloud-hosted [platform] integrations”). The remaining four — team_size, language, pricing_tier, and industry — became filter-only facets, applied with noindex and a self-referencing canonical back to the parent category page.

Parameter rules at the edge. We implemented robots.txt parameter rules and X-Robots-Tag: noindex on filter-only combinations at the Next.js middleware layer, so the URLs still resolved for logged-in users but were removed from the index. This is faster and safer than relying on per-page meta tags that engineering might forget on the next build.

Consolidate, then redirect. Where a filter combination had attracted a handful of external links or residual traffic, we 301-redirected it to the nearest surviving category page rather than simply dropping it, preserving what little equity existed. Roughly 2,400 URLs went through redirects; the rest were collapsed via canonical.

Rewire internal linking. We rewrote the navigation, footer, and in-content links so that every internal link pointed at a canonical category or integration page — never at a filter URL. The “browse by category” menu now linked to the eight indexable category landing pages, which in turn linked down to individual integration pages. This created a clean hub-and-spoke structure that matched how prospects actually search.

Sitemaps and breadcrumbs. We regenerated the XML sitemap to contain only canonical URLs and added breadcrumb structured data so the directory hierarchy was explicit to crawlers. A clean SEO for SaaS companies architecture is less about adding things and more about removing the paths that confuse crawlers — this phase was mostly subtraction.

Because the rules lived in middleware rather than in per-page meta tags, the handoff to engineering was a single configuration file rather than a checklist. We documented the indexable-facet policy as a decision table the team could extend when they added new filters, and added a CI check that failed the build if a new filter combination generated an indexable URL without an explicit policy entry. This is the unglamorous half of faceted-nav work — the technical fix is meaningless if the next release quietly re-introduces the duplication — and it is the reason the indexable URL count held at roughly 6,800 in the quarter after the engagement rather than creeping back toward its old level.

Phase 3 — Authority and content compounding (Weeks 4-8)

With crawl budget now flowing to the right pages, the next job was to make those pages worth ranking. We prioritised the 40 highest-value integration pages identified in Phase 1 and deepened them: genuine integration detail, setup steps, data flows, and use cases drawn from the product team’s own documentation. Thin canonical pages are still thin pages; the architecture fix only matters if the surviving pages deserve to rank.

We added SoftwareApplication and ItemList schema to integration and category pages respectively, so that category pages could earn rich results and individual integration pages carried explicit type signals. We also built a “related integrations” module into each integration page, which created a dense internal link graph inside the directory — every page now linked to three to five semantically related pages, distributing authority horizontally rather than concentrating it at the top.

Orphan recovery ran in parallel. The 580 pages stuck in “crawled — not indexed” were audited: those that were genuine canonical pages got fresh internal links from related pages and the sitemap; those that were legacy duplicates were finally retired. Within four weeks of the relaunch, indexed canonical pages climbed from roughly 560 to over 900, the first clear signal that Google accepted the new architecture.

This phase overlapped with Phase 2 deliberately. Architecture and authority had to land together — fixing crawl without improving the pages would have left the consolidated pages ranking for terms they did not deserve, and improving pages while leaving 60,000 duplicates would have meant the new content never got crawled.

Phase 4 — Measure and compound (Weeks 8-12)

The final phase was measurement and iteration. We tracked three layers weekly: crawl health (fetch distribution from logs), indexation (Search Console coverage), and rankings (position tracking on the 40 priority clusters plus a long-tail sample). The dashboards were shared with both engineering and marketing so the same numbers drove prioritisation on both sides.

The crawl distribution moved first and fastest. By week six, duplicate-URL fetches had dropped from 47% to 11% of daily crawl, and the freed budget was visibly flowing into the canonical integration pages. Rankings followed with a lag, as expected: the consolidated category pages began climbing in weeks four to six, and the individual integration pages followed as their internal authority rebuilt. By week twelve, 47 priority keywords had moved from page two onto page one, and a further long tail of “[tool] + [platform]” queries had entered the top twenty for the first time.

A residual bucket of around 140 “crawled — not indexed” pages remained, mostly legacy integration pages with genuinely thin content. These were queued for a content refresh in the following quarter rather than forced — pushing thin pages into the index helps no one.

Final Results

At the 90-day reporting window, the engagement had shifted the directory from a liability into the company’s strongest organic asset.

Metric	Before	At 90 days
Ranking directory pages in top 20	380	562 (+48%)
Non-branded organic sessions / month	41,000	57,000 (+39%)
Indexable URLs across directories	61,200	6,800 (-89%)
Crawl budget on duplicate URLs	47%	11%
Canonical pages indexed	~560	920
Organic trial sign-ups / month	240	358 (+49%)

The organic trial sign-up number is the one the leadership team cared about most. Because the integrations directory captures prospects at the moment they are evaluating whether the platform fits their existing stack, sign-ups from those pages convert to paid at a higher rate than the site average. A 49% lift in monthly organic trials, on top of the paid funnel, materially changed the channel mix.

What Made This Work

1. Diagnosis came from logs, not tools. Crawl dashboards and SEO platforms estimate what Googlebot does; raw server logs show exactly what it does. Building the remediation plan on log data meant the prioritisation was correct the first time, rather than reacting to tool heuristics that obscured the real duplication pattern.
2. Subtraction before addition. The instinct of most teams is to publish more pages. Here, removing 89% of indexable URLs is what created the space for the remaining pages to rank. The fastest win was deleting crawlable junk, not building new content.
3. Indexability tied to search intent. The decision rule — a facet is only indexable if it maps to a query a prospect actually types — kept the architecture honest and made future governance simple. Engineering could ship new filters without reopening the cannibalisation problem, because the rule was encoded in middleware.
4. Architecture and authority landed together. Collapsing URLs and deepening the surviving pages in overlapping sprints meant Google reprocessed a clean, improved site in a single crawl cycle. Doing either in isolation would have produced a weaker, slower result.
5. Internal linking rewired to canonical pages. Authority that had been draining into filter URLs was redirected to the pages meant to rank. This single change did as much for the priority pages as the canonical rules themselves.

What Teams Can Apply

1. Audit your URL-to-canonical ratio. If your indexable URL count is more than 5-10x your intended ranking pages, faceted navigation or parameter handling is almost certainly diluting your authority. Pull a crawl and a Search Console coverage export and compare the two numbers before doing anything else.
2. Decide facet indexability by intent, not by convenience. For every filter on your site, ask whether a real person searches for that combination. If they do not, it should be noindex with a self-referencing canonical — still useful for logged-in users, invisible to Google.
3. Encode the rules in code. Parameter rules enforced in middleware or server config cannot be forgotten on the next release. Per-page meta tags can and will be.
4. Measure crawl health, not just rankings. Rankings lag crawl changes by weeks. If you watch only rank trackers, you will lose confidence in a correct fix before it has time to compound. Log-based crawl distribution tells you within days whether the architecture change is working.
5. Pair the technical fix with page quality. Architecture creates the opportunity; content converts it. A directory cleanup that leaves the surviving pages thin will underperform — budget for deepening the canonical pages in the same engagement.

For Pakistani B2B SaaS and software companies running similar filterable directories — whether integrations, marketing for SaaS feature pages, partner listings, or documentation hubs — this framework transfers directly. The local variables (language variants, regional deployment demand, Urdu and English query mix) change which facets are indexable, but the crawl-governance mechanics are identical.