AEO for Which Queries

TL;DR

"Which" queries ("which language for backend", "which laptop for video editing", "which CRM for a 10-person sales team") are recommendation queries. Win them by leading with a default verdict, mapping 3-5 personas to specific picks. Providing a scoring table with weights so an AI engine can re-rank if the user adds a constraint. Avoid "it depends" answers without enumerated branches—they look unhelpful and reduce citation likelihood (Google Search Central, 2024).

Why "which" queries are harder than "vs" queries

A vs query has two named entities and a finite criteria axis. A which query has one open slot ("which X") plus a context ("for Y"), and the candidate set may be 5-20 entities. The reader is asking for a recommendation, not a comparison. They want one of three outputs:

1. A single default pick that works for the modal user.
2. A persona-mapped pick when their context differs from the modal user.
3. A decision tree when the choice depends on multiple constraints.

Generic "top 10" listicles fail at all three: they enumerate without recommending, hedge without committing, and rank without explaining the weights. AI engines treat unranked listicles as low-confidence input and prefer pages with explicit recommendation logic.

The recommendation page structure

A strong which-query page follows a six-block layout.

1. Default-pick callout

One sentence that names the pick under the most common context. Format as a callout or blockquote.

Default pick: For most 10-50 person SaaS companies, choose HubSpot CRM Free for the first 12 months, then upgrade to Sales Hub Starter when your pipeline exceeds 1,000 active deals.

2. Persona-to-pick mapping

Under a single H2 (## Which one to choose), provide 3-5 persona blocks. Each is a bolded persona label followed by the pick and the one-line rationale.

• Solo founder, pre-revenue: Use a free tier or open-source option to keep burn low; revisit at first hire.
• 10-50 person SaaS: Pick a mid-market option with strong API and an upgrade path; favor net-revenue-retention features.
• 50+ enterprise with compliance needs: Choose a vendor with SOC 2 Type II, audit trails, and SSO standard.
• Agency or consultancy: Multi-tenant support and per-client billing matter more than depth in any single feature.

This block is extraction gold for conversational engines because it maps user attributes directly to a recommendation (OpenAI, 2024).

3. Scoring table with weights

A scoring table assigns weights to the criteria, scores each candidate against each criterion, and computes a weighted total. The reader can re-weight criteria mentally if their priorities differ.

Weights should reflect the modal user. Show the math so an engine can re-cite a different pick when a user changes the weight ("if API matters most, choose Tool A").

4. Decision tree for edge cases

A short decision tree (3-6 nodes) covers the common branches. Format as a numbered list of conditional questions with terminal recommendations.

1. Is the team under 10 people? → Use the free tier of Tool C.
2. Is the team between 10 and 50? → Use Tool A with the Starter plan.
3. Are SOC 2 or HIPAA required? → Override to Tool B regardless of size.
4. Is the budget under $500/month? → Stay on Tool C and revisit at the next funding round.

Decision trees are explicitly supported by the structured-question patterns conversational engines use to disambiguate (Anthropic, 2024).

5. Trade-off discussion

A short H2 that names the two or three honest trade-offs ("Tool A is cheaper but slower", "Tool B locks in but ships faster"). Do not paper over weaknesses—trust-aware engines downweight pages that read as advertorial.

6. FAQ for adjacent recommendations

Close with FAQs for adjacent intents: "What if I am also evaluating Tool D?", "How long do these recommendations stay current?", "What if I outgrow the recommendation?".

Five worked examples

Example 1: Programming language

Query: "which language for a high-throughput backend"

Default pick: Go for new services where concurrency dominates and the team is comfortable with static typing. Persona blocks split by team background (Python, Java, JavaScript, polyglot), team size, and existing service mesh. Scoring table weights concurrency model, ecosystem maturity, hiring pool, and operational footprint.

Example 2: Database

Query: "which database for a multi-tenant SaaS"

Default pick: Postgres with a tenant-id-per-row pattern for most early-stage SaaS, with the option to shard or move to Postgres-on-cloud (Aurora, Supabase, Neon) at scale. Decision tree handles strict isolation needs, regulated industries, and read-heavy analytics workloads.

Example 3: Project management tool

Query: "which project management tool for a 50-person product team"

Default pick: Linear for engineering-heavy teams, Asana for cross-functional teams, Jira for regulated or PMO-led organizations. Persona blocks split by engineering ratio, compliance, and reporting cadence.

Example 4: AI model

Query: "which model for production summarization at scale"

Default pick: A mid-size frontier model (e.g., GPT-4o-mini or Claude Haiku class) with caching for high-volume summarization, a frontier model fallback for failure cases. A fine-tuned small model when latency matters most. Trade-offs cover cost vs quality and the operational burden of self-hosting.

Example 5: Cloud provider

Query: "which cloud for a small startup"

Default pick: AWS for breadth and hiring pool, Google Cloud for data and AI workloads, Cloudflare for edge-first products, and Fly.io or Render for early-stage simplicity. Decision tree covers funding stage, regulatory geography, and team experience.

Common mistakes

1. No default pick. "It depends" without enumerated branches reads as evasive. Always commit to a modal-user recommendation.
2. Listicle without ranking logic. Top 10 lists where every item is "the best for some teams" lose to pages that show the weighting.
3. Hidden weights. A scoring table without weights is a flat comparison. Show the weights and explain them.
4. Static personas. Personas like "large enterprise" without size or compliance criteria are not extractable. Use numeric or boolean attributes ("50+ employees", "SOC 2 required").
5. Promotional ranking. If the top pick is also the affiliate with the highest commission, disclose it. AI engines and editors flag this fast.
6. Stale recommendations. Recommendations decay as products change. Set a 90-day review cycle and update dateModified accordingly.
7. No re-rank guidance. Engines re-rank when users add constraints. Provide explicit "if X matters most, pick Y" lines.

Implementation checklist

• [ ] Default-pick callout in the first 150 words
• [ ] 3-5 persona blocks with attribute-anchored personas
• [ ] Scoring table with weights and explicit math
• [ ] Decision tree with 3-6 conditional branches
• [ ] Trade-off section naming honest weaknesses
• [ ] FAQ with 4-6 adjacent-intent questions
• [ ] Inline citation on every numeric or pricing claim with a date marker
• [ ] Hub link to /aeo/ and 3-5 sibling article links

FAQ

Q: What if there is genuinely no default pick?

There usually is—for the modal user. If the modal user is unclear, define one explicitly ("For a 10-50 person SaaS company in North America...") and give the default pick under that definition. Then handle the other contexts in persona blocks.

Q: How many candidates should the page consider?

Cover 3-7 candidates in depth. More than seven and the scoring table becomes noisy; fewer than three and the page reads as a single-vendor pitch.

Q: Should I rank by total score?

Yes, but show the weights and let the reader re-rank by changing the weights. The total is the default ranking; the methodology is what makes the page citable.

Q: How do I keep recommendations fresh?

Review every 90 days minimum, and immediately when any candidate ships a major release or pricing change. Update updated_at and any (as of YYYY-MM) markers in the body.

Q: Is it acceptable to recommend a free or open-source default?

Yes—it is often the right answer for early-stage teams. The page should also identify the realistic upgrade trigger so the reader knows when to revisit.

Q: How do I avoid sounding like a sponsored post?

Disclose any commercial relationship, name honest trade-offs, and cite primary sources for every numeric claim. The page should be defensible to an editorial reviewer who has no commercial interest.