Bottom-of-funnel pages for SaaS: use-case, alternative, comparison and integration pages that stay out of doorway territory

A SaaS buyer near the end of a decision searches differently from someone learning about a category. They type the name of the tool they use now plus "alternative". They type two product names with "vs" between them. They type the job they need done, or the name of the app your product has to connect to. Pages built for those searches are usually called bottom-of-funnel (BOFU) pages.

Some practitioners argue that these pages convert better than blog posts. I have not found a published dataset that shows this in general, so I treat it as a hypothesis you test on your own funnel, not a fact. This article is a method. It makes no claims about results.

Every claim below carries one of four labels: official guidance (a platform or regulator documenting its own rules), research finding, our observation, or hypothesis. The Google pages were checked on 2026-10-06. Re-check them before you rely on this after early 2027.

The four page types and when each fits

The type of page should follow the buyer's decision, not a keyword list. Before you build one, search the query yourself and look at what already ranks. If the results are listicles from review sites, a single vendor page may not match what searchers want. If they are vendor pages and documentation, it probably does. (Our method, hypothesis. Google publishes no rule that a page must match the format of what already ranks.)

Page type	The buyer's question	Build it when	Skip it when
Use-case page	"Can this tool do my job?"	A distinct group of customers uses the product for a distinct job, with its own setup, limits or pricing	The only difference from the next page would be the job title in the heading
Alternative page	"I'm leaving Tool X. What else is there?"	You win real deals from Tool X, and you can state honestly why someone switches and why they might not	You have never compared the products hands-on, or you only want to borrow X's brand traffic
Comparison page ("A vs B")	"Which of these two should I pick?"	Buyers actually shortlist you against B, and you have current, checkable facts on both	You can't keep B's details up to date
Integration page	"Does it work with the app I already use?"	The integration exists, is supported, and has real setup steps, data fields or limits worth documenting	It's a logo on a grid with nothing to set up or explain

Two rules apply across all four (our method, hypothesis, register M1-31):

1. One page per distinct decision. Two queries that bring up the same results and need the same answer get one page.
2. Each page carries facts no sibling page carries. If you could swap the competitor or app name and nothing else would need to change, you have a template, not a page.

Page shape: what goes on each page

Google says there is no target word count, minimum or maximum (official guidance, SEO Starter Guide, M1-05). Its people-first guidance lists writing to a word count as a warning sign (official guidance, M1-09). Write the length the decision needs. A short integration page with exact setup steps can be complete. A comparison page usually needs more.

A shape that works for most BOFU pages (our method, hypothesis):

• Answer the question near the top. For an invented example, "Yes, it syncs contacts both ways, every 15 minutes, on all paid plans" is an answer. "Seamless integration for modern teams" is not.
• Specifics a buyer can check. Supported plans, limits, data fields, setup time from your own tests, what isn't supported.
• Proof from your own product. A screenshot of the real setup screen, a working config snippet, a short clip. Google's AI search guide asks for first-hand content others can't easily copy (official guidance, AI optimization guide, M1-13).
• Who it's not for. One honest paragraph, so a buyer who won't fit can rule you out early.
• One next step that matches the page: a trial with the integration preselected, a migration guide, or a demo.
• A visible "last checked" date for any facts that change, especially competitor facts.

What not to bother with. Google ignores the keywords meta tag, says keywords in the URL have "hardly any effect", and says heading order doesn't matter to Search (official guidance, M1-06). It builds title links and snippets automatically and may replace a poor title (official guidance, title links, M1-08; snippets, M1-07). Write one clear, distinct title per page and stop there. For Google's AI features there is no special markup, no llms.txt, and no need to split content into chunks (official guidance, M1-13).

Where the doorway line actually sits

Google's spam policy on doorway abuse describes pages created to rank for specific, similar queries that send users to intermediate pages less useful than the final destination (official guidance, spam policies, page dated 2026-08-28, M1-01). Its examples include:

• many near-identical pages or domains, each aimed at a city or region, that all funnel to one page,
• pages that exist to funnel visitors to the useful part of a site,
• substantially similar pages that sit closer to search results than to a browseable hierarchy.

What the policy does not say matters just as much. It does not ban templates, location pages or comparison pages as a format. It gives no page count, no similarity percentage and no safe rollout speed (M1-01). Anyone quoting a number is quoting their own heuristic.

Two neighbouring policies apply to BOFU sets:

• Scaled content abuse: many pages made mainly to manipulate rankings, with little value to users, no matter how they are produced. Google gives generating a page per query variation as one example (official guidance, M1-02, M1-13). Using AI is not a violation in itself, but Google asks you to fact-check every AI-written field, including titles, descriptions, structured data and alt text (official guidance, AI-generated content, M1-12).
• Keyword stuffing: Google's examples include blocks of text listing the cities and regions a page wants to rank for (official guidance, M1-27). A paragraph listing twenty competitor names "for SEO" looks like the same pattern to me. That is my analogy, not Google's wording (hypothesis).

So the useful test is about purpose and value. For each page in a set, ask:

1. Would this page exist if search engines didn't? Would a buyer or salesperson send someone to it?
2. Does it hold facts a sibling page doesn't (setup steps, limits, pricing differences, migration details)?
3. Can someone reach it from your normal navigation, docs or integration directory, or does it only exist for search?
4. Does it complete the task, or does it just push the visitor on to a "real" page?

A set of 40 integration pages, each with real setup steps and field mappings, linked from an integrations directory, passes all four. A set of 40 "[Competitor] alternative" pages with the same three paragraphs and a swapped name fails all four. Most real sets fall in between. Prune or merge the weak pages before you publish more. (Test: our method, hypothesis, M1-31. Some practitioners describe a traffic spike followed by a crash after large template rollouts. That shape is practitioner consensus, not a measured curve, M1-23.)

Honest comparison pages

A vendor comparing itself to a competitor has an obvious interest, and readers can see it. The page earns trust only if it's accurate where that interest pulls the other way.

What the rules say. In the US, the FTC's policy on comparative advertising supports naming competitors in truthful comparisons. It applies the same substantiation standard to comparative claims as to any other ad claim (official guidance, FTC policy statement, 1979, M1-28). The FTC's Endorsement Guides FAQ says material connections, such as employment or affiliate commissions, must be disclosed clearly and close to the claim (official guidance, FTC FAQ, M1-29). Other countries have their own rules. This isn't legal advice, so have counsel review comparison pages before they go live.

What Google suggests for reviews. Google's review guidance asks writers to explain what sets a product apart, cover comparable options or say which suits which use, and back claims with first-hand evidence (official guidance, high-quality reviews, M1-25). It is written for reviewers, not vendors. Applying it to your own comparison page is my reading (hypothesis), but it's a sensible standard.

The rules I'd hold a comparison page to (our method, hypothesis):

1. Say who wrote it. One line near the top: "We make Product A. This comparison is ours." Disclose any partner or affiliate payment.
2. Date every competitor fact. "Tool B's Team plan lists 10 seats as of 2026-10-06, per its public pricing page", with a link. Facts without dates go stale.
3. Only state what you can show. A public page, a documented test you ran, or a dated screenshot. If you didn't test it, don't claim it.
4. Give the competitor its real strengths. Include a "choose B if…" section that a B customer would agree with.
5. Compare the same things. Plan against equivalent plan, list price against list price, the same feature definitions on both sides.
6. Review on a schedule. Every quarter, and whenever either product changes pricing or a major feature. Keep a change log. Update the date only when the substance changes. Google lists changing dates just to look fresh as a warning sign (official guidance, M1-09).
7. Fix complaints fast. If the competitor flags an error, check it and correct it publicly.

Will comparison pages get you cited in AI answers? Some vendor studies say so. I haven't verified their samples, dates or engines, so this stays a hypothesis (M1-22). Google's own AI guide names no page format that earns citations (M1-13). Build comparison pages for the buyer, then measure citations separately.

A measurement plan

Measure BOFU pages as a set against something you didn't change. Otherwise launches, campaigns, seasons and Google updates will look like results. A before/after change on its own doesn't show cause.

1. Write down a baseline before launch. For each page: target query group, launch date, sibling pages, and the conversion event it should drive (our method).

2. Search Console, Performance report (official guidance, M1-15, M1-16):

• Filter by page to see each BOFU page's clicks, impressions, CTR and average position.
• Filter queries with a custom regex to group intent, for example alternative|vs|versus|compare|integrat. Regex filters use RE2 syntax, match partially and ignore case by default.
• Expect gaps. The table shows at most 1,000 rows. Rare, anonymized queries are dropped once you apply a query filter, so filtered totals undercount. Treat intent-group totals as estimates.
• The separate Generative AI report, available to all sites since its rollout completed on 2026-08-31, shows AI Overviews and AI Mode impressions by page, country, device and date (official guidance, M1-17). AI feature traffic is also counted in the main report under the Web search type (official guidance, M1-14). Look in the UI before assuming the AI report shows clicks. We haven't confirmed that.

3. Conversions. In GA4, mark the events that matter as key events: trial start, demo request, integration connected (official guidance, GA4 key events, M1-30). Report them by organic landing page. Then join to the CRM for what search tools can't show: qualified opportunities, activation and retention by first landing page. A signup that churns in a week isn't a win.

4. A control set. Pick similar pages you won't change during the test window. Compare equal time windows and note every product launch, campaign and announced Google update.

5. Size the test honestly. Low-traffic B2B sites often can't detect small changes. Decide the smallest effect that would change your decision, and check whether you have the volume to see it (standard experiment-design practice; see Kohavi, Tang and Xu, M1-24). If you don't, report what you saw as an observation, not a result.

6. Keep AI mentions separate. Mentions in AI answers, linked citations, referral sessions and signups are different numbers. Track each one separately and don't add them together.

Checklist

Before you build:

• The query shows a buying decision and you've checked the live results.
• No existing page already answers the same decision.
• You have facts for this page that no sibling page has.

On the page:

• The answer is near the top, in plain words.
• Specifics a buyer can check: plans, limits, setup steps, what isn't supported.
• Your own proof: screenshots, config, test notes.
• A "who it's not for" paragraph.
• One next step that matches the page.
• One clear, distinct title. No keyword lists.
• Every AI-drafted field fact-checked, including title, description, schema and alt text.

Comparison and alternative pages:

• You state who wrote it and disclose any payments.
• Every competitor fact is dated and sourced.
• Includes a fair "choose them if…" section.
• Like-for-like plans and definitions.
• Review date and change log. The date changes only when the content does.
• Legal review where your market requires it.

The set as a whole:

• Reachable from normal navigation or a directory, not only from search.
• Passes the four doorway questions above. Weak pages merged or removed.
• Baseline, control set and key events in place before launch.

If you want help working through this on your own site, RankPropel's audit and baseline sprint covers priority pages, the conversion path and lead-source measurement. The method works the same if you run it yourself.

Sources

Google Search Central: spam policies (doorway abuse, scaled content abuse, keyword stuffing; page dated 2026-08-28), SEO Starter Guide, creating helpful, people-first content (page dated 2026-10-05), using generative AI content, optimizing for generative AI search, title links, snippets, high-quality reviews. Search Console Help: Performance report, regex filters, Generative AI report. Google Analytics Help: key events. US FTC: comparative advertising policy, Endorsement Guides FAQ. Kohavi, Tang and Xu, Trustworthy Online Controlled Experiments (Cambridge University Press, 2020). All retrieved 2026-10-06.