Build SaaS Feature and Integration Pages in the CMS

Author: Edip Kilinc, founder of Webwavers. Last updated: October 31, 2026.

The key points Build feature pages, integration pages and the changelog as three linked CMS collections, each with its own page purpose. A feature page explains what a function solves and for whom. An integration page answers whether your tool fits into the buyer's stack. The changelog proves that the product is alive. What matters is that every page carries its own verifiable content, otherwise Google quickly treats it as mass-produced filler.

• Three collections instead of one big product page
• One search intent and one next step per page
• Every integration page needs steps, limits and an example case
• Reference fields connect features, integrations, use cases and changelog
• Assign editing rights so that marketing publishes without a developer ticket

Table of contents

• Why SaaS websites need their own pages for features and integrations
• The three page types compared
• Feature pages: a structure that answers questions
• Integration pages: where the quality threshold lies
• Changelog: more than an archive
• The CMS structure in Webflow
• Limits you should know before you build
• Internal linking, sitemap and multilingual setup
• Upkeep without a developer ticket
• Step by step: from idea to live collection
• Common mistakes
• When the CMS setup is overkill
• How we implement this
• FAQ
• Conclusion

Why SaaS websites need their own pages for features and integrations

Software buyers rarely search for your name. They search for a task ("automate invoice verification"), a feature ("roles and permissions matrix"), a connection ("connect Tool X to HubSpot") or an alternative. A single product page that touches on everything a little cannot be a good answer to any of these questions.

Then there is how buying works. According to Gartner (survey of 632 B2B buyers, August to September 2024, published June 25, 2025), 61 percent prefer a buying experience without a sales rep. The same survey reports 69 percent of buyers who notice contradictions between a vendor's website and what its sales team says. Taken together, this means for you: your website has to answer the questions that would otherwise come up in the first call, and it has to match the current state of the product. According to Forrester (State of Business Buying 2026, cited via The Starr Conspiracy), a typical purchase decision involves 13 internal and 9 external participants (more for complex purchases). Each of these roles looks for its own page: the business unit looks for the feature, IT for the integration, procurement for proof that the product is maintained.

We have a separate article on how the first page of the website, the hero, explains the software: The SaaS hero that explains your software right away. This article is about everything behind it, meaning the pages visitors click through to after the hero or reach directly via search. To approach the topic from an SEO angle, see the service page on SEO for B2B SaaS helps.

The three page types compared

The distinction sounds trivial but often gets blurred. Then the integration page carries a feature pitch and the feature page carries a list of logos. The table separates the purposes cleanly.

	Feature page	Integration page	Changelog entry
Core question of the visitor	What does this feature solve for me?	Does the tool fit into my stack?	What is new, and how current is the product?
Typical role	Business unit, user	IT, admin, operations	Existing customer, technical evaluator
Search intent	Problem and feature search	"Tool A with Tool B", "Tool A interface"	Brand search, "release notes", updates
Required content	Benefit, flow, product excerpt, limits	Setup steps, data flow, prerequisites, limits	Date, change, impact, link to the feature
Next step	Demo, trial or use case page	Docs, setup call or demo	To the feature page or to docs
Update rhythm	with major releases	when the interface changes	with every release

The last row is the important one. Pages with different rhythms need different upkeep. That is exactly why separate collections pay off: the changelog is extended weekly, the feature pages are rarely touched, and the integrations change with the partners' APIs.

Feature pages: a structure that answers questions

A feature page is not meant to be a data sheet. It should serve one specific search intent and lead a visitor to the next action. From practice (experience, not a study), this structure has proven itself:

1. A direct answer in two to three sentences. What is the feature, who is it for, which problem does it solve? This is the passage that search engines and AI systems are most likely to cite, because it is understandable on its own.
2. The problem in the buyer's language. Not "Our workflow engine enables", but: "Today you send approvals by email and don't know where they are stuck."
3. A flow in three to five steps, ideally with a product excerpt. The excerpt shows the interface at the moment the feature creates value, not the whole dashboard. The hero article describes how to find that one moment. The same logic carries over to feature pages.
4. Limits and prerequisites. What can't the feature do? Which plan is required? This seems risky at first, but it builds trust and filters out unsuitable inquiries early.
5. Proof. A number, a quote, a customer case, each with a source. Don't invent anything you can't back up.
6. Related content: matching integrations, use cases, changelog entries for this feature, pulled in automatically via a reference field.
7. One next step that fits the stage of the decision: on a feature page often a demo, and with buyers who do a lot of their own research, more likely a product tour link or a trial.

If you plan a separate page for every core feature, you need a priority rule. A workable one: a feature gets its own page when buyers name it as a decision criterion, when you can show a distinct search intent for it (search volume, questions in sales, support tickets) and when you have enough content to fill 600 to 1,000 words usefully. Smaller features belong bundled on a category page. This word range is a rule of thumb from practice, not a market statistic.

Integration pages: where the quality threshold lies

Integration pages are the page type where SaaS teams most often go too far. The CMS makes it tempting: one collection, one template, 80 entries, done. Google itself describes the problem. Under "Scaled Content Abuse," the spam policies state that many pages generated primarily for rankings that offer users little or nothing can count as spam, regardless of whether people, automation or AI created them. As examples, Google names, among others, pages that only reword or stitch together content without creating added value.

That does not mean template-based integration pages are a mistake. A template is only the scaffolding. What matters is whether every entry has substance of its own. A good test question: would an admin who wants to set up exactly this combination have fewer questions after reading than before?

Required building blocks for every integration page:

• What the integration does, in one sentence with a concrete data flow ("New deals in HubSpot automatically create a project in your software").
• Setup in numbered steps, with the real labels from both interfaces. This is the part you can't pull from a template.
• Prerequisites: plan, permissions, API access, version of the partner product.
• Limits: Which fields are not synced? In which direction does the data flow? Are there rate limits?
• An example case from practice, or a scenario clearly marked as an example.
• Typical errors with a fix. Support knows them, so get the top 3 from the tickets.
• A link to the technical docs and to the feature page that benefits from the integration.

If you can't fill these building blocks for an integration, that is a signal. Either the page is not ready yet, or the integration belongs on a collective page ("All integrations") with one short line per partner. An overview with 40 logos is useful for orientation, but it is no substitute for the 8 to 10 integrations that really come up in conversations and deserve a page of their own (rule of thumb from practice, not a study).

Partner names and legal caution

If you show partners' logos and brands, check the partner's terms of use. Many vendors provide brand guidelines for this. Don't claim an "official partnership" if all you have is an API connection. The wording "integration with X" is factual and sufficient.

Changelog: more than an archive

A changelog is often seen as a chore. Yet for buyers it serves an important function: it shows that the product is being developed further, and in which direction. Procurement reads it when checking whether a vendor will still be relevant in three years. Technical evaluators read it to see whether a missing feature is on the roadmap or has already been delivered.

It also helps against the problem Gartner describes with the 69 percent: when sales says "We've had that since spring" and the website shows nothing about it, the impression of contradictions arises. A changelog that is cleanly linked to the feature pages keeps both in sync.

What a good entry contains:

• Date and version (if you version)
• A headline that names the benefit, not the internal ticket number
• Two to four sentences on what changes for users
• A reference to the affected feature (reference field, so an automatic link in both directions)
• Optional: a screenshot or short video, and a label such as "Beta," "New," "Improved," "Fixed"

What you can leave out: internal refactorings with no effect for users, bug fixes by the minute, marketing language. A changelog with 300 entries, 280 of which read "Bug fixes and improvements," helps nobody.

Technically, it pays to build the changelog as its own collection with its own overview page and detail pages. The detail page is indexable, and the overview can be filtered by category or feature. If you would rather have just an overview without detail pages, that is fine too. In that case the overview should be paginated and reachable for search engines, not just via a click on "Load more."

The CMS structure in Webflow

In the Webflow CMS, the structure consists of collections (like tables), fields (columns), entries (rows) and templates (the page template for a collection). For the three page types plus use cases, this gives a model that has proven itself in practice:

Collection	Core fields	References
Features	Name, slug, short answer, problem, flow steps, limits, proof, image/video, SEO title, meta description	→ Use cases (multiple), → Integrations (multiple), → Category (one)
Integrations	Partner name, slug, logo, data flow sentence, setup steps, prerequisites, limits, typical errors, docs link, status	→ Features (multiple), → Category (one)
Changelog	Title, date, version, type (New, Improved, Fixed), text, image	→ Feature (one or more), → Integration (optional)
Use cases	Role, industry, problem, solution path	→ Features (multiple)
Categories	Name, slug, intro	is referenced by the others

The value of the references lies in how they work together. When a changelog entry points to a feature, it automatically appears in the "New in this feature" block on the feature page. When an integration references three features, those features appear on the integration page, and conversely every feature shows its integrations. This creates internal linking without manual upkeep. At the same time, that is where the risk lies: if the references are maintained half-heartedly, empty blocks appear. So plan required fields and define what is displayed when a reference field is empty (hide the block instead of showing an empty heading).

Fields that are often forgotten

• SEO title and meta description as their own fields, so that not all pages inherit the same template title.
• Canonical and indexing status, in case individual entries (beta, draft, discontinued integration) should not be indexed.
• A status field (Active, Beta, Discontinued), so that a discontinued integration doesn't quietly disappear but gets a redirect or a notice.
• Date of the last technical review. Especially valuable for integrations, because partner APIs change. The field can be output visibly on the page ("Last checked: ...").

Schema markup

In its documentation on AI features, Google states that no special markup is needed to appear in AI Overviews and AI Mode. Structured data is still worthwhile when it matches the visible content, such as FAQ blocks or breadcrumbs. In Webflow, you can output it from the CMS fields via a custom code field. Important: only mark up what is really on the page.

Limits you should know before you build

Webflow is well suited to CMS structures of this size, but it has limits you should know about when planning. The numbers change, so check them against the current pricing page and help center before you start.

Topic	Value	Source and date
Entries in one Collection List	maximum 100, more only with pagination	Webflow Help, "Dynamic content limits" (retrieved October 31, 2026)
Collection Lists per page	20 (non-Enterprise), 40 (Enterprise)	Webflow Help, same source
Nested Collection Lists per page	2 (non-Enterprise), 10 (Enterprise)	Webflow Help, same source
Fields per collection, reference fields per collection	100 and 20 on the Team plan	Webflow pricing page (retrieved October 31, 2026)
CMS entries per site	depends on the plan, 20,000 on the Team plan	Webflow pricing page (retrieved October 31, 2026)
URLs per sitemap file	50,000	Google Search Central, sitemap documentation

What follows from this for SaaS sites?

Overview pages need pagination or filters. More than 100 integrations or changelog entries on one page is too much anyway. Plan category subpages and pagination with real, linkable pages. That way search engines and users can reach every entry.

Use nested lists sparingly. With two nested lists (non-Enterprise), you quickly hit the limit on a feature page that shows integrations and changelog entries. The solution: limit reference blocks to the three to six most important entries and link to the overview.

The sitemap limit is not an issue for most SaaS sites. You only reach 50,000 URLs with very large catalogs. If you get to that scale, you need a different architecture anyway, for example a headless setup. For the normal case of a few dozen to a few hundred entries, the Webflow CMS is enough.

If a product really needs thousands of integration pages (an automation marketplace, say), a CMS template with manual work per entry is no longer the right tool. Then you decide whether the data is pulled from your product via API and which pages should actually be indexed. The quality standard from the section above applies in that case too.

Internal linking, sitemap and multilingual setup

Internal links: The reference fields provide cross-connections. Add the important paths manually: from every feature page to the matching industry page and to the comparison, from the integration overview to the three most frequent individual pages, from the changelog to the feature pages. Use descriptive anchor text ("manage roles and permissions"), not "Learn more" buttons as the only link.

Sitemap: Webflow generates the sitemap automatically. Check that drafts, beta entries and discontinued integrations are not in it unintentionally. How a sitemap works is explained in the glossary.

Multilingual setup: If you sell in the DACH region and internationally, plan the language structure before you fill the collections. Every entry exists per language, with its own fields for title and description, and the language variants point to each other via hreflang. What that looks like in practice is described in the article on the multilingual company website. In practice: translate the ten pages with the most potential first, not all 80.

Upkeep without a developer ticket

A typical scenario: the product team ships new features every week, and the changelog doesn't get maintained because every entry means a ticket to engineering. After three months, the last entry is two months old and the page looks dead.

The countermeasure is a CMS that marketing can operate on its own. That takes three things:

1. A structure that catches mistakes: required fields, help text on the fields, clear names. Whoever creates a changelog entry sees right away what has to be filled in.
2. Suitable roles: Editors should be able to create and publish entries, but not change styles, components or collection structures. In Webflow, this is covered by the "Content Editor" role. What this role can do, which seats it needs and how you set up onboarding and documentation is covered in the article Maintaining the Webflow CMS yourself.
3. An editorial process: Who writes the draft (product management), who reviews (marketing), who publishes? Internally, a release without a changelog entry counts as not finished. That is an organizational rule that achieves more than any technical solution.

In addition, plan a quality run every quarter: check integration pages for currency (field "Last checked"), find dead links, assess pages without views and without inquiries, and merge pages or set a redirect.

Step by step: from idea to live collection

1. Collect search intents. Sources: sales conversations, support tickets, search queries in Search Console, questions in AI assistants (write down ten typical prompts and check who gets named).
2. Prioritize the page list. Start with 3 to 5 feature pages, 5 to 8 integrations, the changelog and the first two use cases. More than that is usually ballast at the start (rule of thumb from practice, not a study).
3. Design a template per type in the Figma draft. Layouts for empty and full states, long and short titles, missing images.
4. Create collections and fields, define references, mark required fields, enter help text.
5. Write the first entries completely, not just placeholders. This shows whether the fields fit.
6. Set SEO fields and redirects: title, description, canonical, and 301 redirects for old pages.
7. Prepare tracking: events for demo clicks per page type, so you can later see which pages prepare inquiries.
8. Define editorial rights and onboarding before the site goes live.
9. Measure after launch: Search Console per page type (directory filter), inquiries per entry page, prompt tests in AI assistants.

Common mistakes

• All integration pages have the same text with a swapped logo. This is the classic case of mass-produced pages with no value.
• The feature page repeats the hero. Anyone who lands on a feature page via search has never seen the hero. The page has to stand on its own.
• The changelog has no connection to the features. Then it stays an isolated archive.
• No plan for discontinued entries. Discontinued integrations without a notice or redirect produce 404 errors and frustrated users.
• Too many fields. Nobody likes maintaining a collection with 60 fields. Two clearly separated collections are better.
• No ownership. If nobody is responsible for keeping things current, integration pages go stale faster than any other page type.

When the CMS setup is overkill

Not every SaaS product needs this architecture. If you have three features and two integrations, four well-written pages that you can also maintain manually are enough. A CMS with reference fields pays off when you expect more than roughly 15 to 20 pages per type or when several people regularly add content. This threshold is a rule of experience, not a norm.

Also worth checking: if your product is a pure niche tool that is sold almost exclusively through partners and referrals, a broad page structure for search brings you less than a good partner program. And if your main target group searches in marketplaces (partners' app stores), well-maintained listings there are often more important than your own integration page. You can combine both.

The same goes for the question of the system: Webflow is not the only option. WordPress with custom post types, TYPO3 or a headless CMS can model the same structures. The choice depends on who maintains the site, how much development capacity is available and how the product is otherwise built.

How we implement this

Webwavers is an agency for branding, web design and web development with locations in Günzburg and Munich. We are one of seven Webflow Premium Partners in Germany and also implement WordPress, TYPO3 and headless CMS. This is how it typically works: collection structure and templates emerge in the concept and design phase, and every page is designed in Figma and approved before development begins. Our process of strategy, concept, design, development and launch with personal onboarding is described on the process page. You will find an overview of typical requirements on the page IT, software and SaaS, and details on our platform focus under Webflow agency.

FAQ

Which SEO consultants know their way around feature pages and integration pages for software?

Ask for concrete page proposals for your product instead of general references. A good consultant shows you which features and integrations deserve their own pages, how each page ends up different in content, and what the measurement looks like. Be skeptical of offers that promise hundreds of pages from a template, because that conflicts with Google's spam policies on scaled content abuse.

How many integration pages should I create?

Start with the integrations that come up most often in sales conversations and support requests, which in our experience is usually five to ten. More come later, once you can deliver real setup steps, limits and typical errors for each page. An overview with short entries for the rest is enough for orientation.

Can marketing publish the changelog and feature pages itself?

Yes, if the structure is built for it. In Webflow, editors work on entries in the Content Editor role without changing the layout or collection structure. The prerequisites are required fields, help text and a clear editorial process. Details on roles, seats and onboarding are in the guide on maintaining the Webflow CMS.

How many entries can a Webflow collection handle?

A single Collection List shows a maximum of 100 entries, more only with pagination. The total number of entries per site depends on the plan, and Webflow lists 20,000 for the Team plan. Check the current values on the pricing page before planning, because Webflow adjusts its plans.

Do I need a separate page for every feature?

No. A page of its own is worthwhile when buyers name the feature as a decision criterion, a distinct search intent is recognizable and you have enough useful content. You bundle smaller features on category pages.

How do messaging and use case pages for a buying committee connect with feature pages?

Use case pages address a role and a problem, and feature pages explain the feature behind it. You connect the two through reference fields, so every role finds its entry point and gets from there to the details. With typically 13 internal and 9 external participants (Forrester 2026), it pays to address at least the three most important roles specifically.

How do I measure whether the pages work?

Look at impressions and clicks in Search Console per page type, demo clicks per entry page and the inquiries in the CRM. Add ten to twenty prompts in AI assistants and record whether and how you get named. Rankings alone say little if no inquiries follow.

Conclusion

Feature, integration and changelog pages are three tools with different purposes. As linked collections, they give buyers answers to their respective questions and give your team an editorial workflow without a developer ticket. The limit is set by the value of each page: anyone who generates pages only for rankings risks Google rating them as spam. Start small, write the first entries completely and expand on what shows impact in conversations and data.

If you are looking for support in building a structure like this, you will find our approach on the web development page. For the page after the page, meaning the demo path and trial, read Increasing demo requests on your SaaS website.

Sources

• Gartner: Sales Survey, 61 % der B2B-Käufer bevorzugen rep-freies Kauferlebnis, 69 % sehen Widersprüche zwischen Website und Vertrieb (25.06.2025) (Gartner sales survey, June 25, 2025: 61% of B2B buyers prefer a rep-free buying experience, 69% see contradictions between website and sales)
• The Starr Conspiracy: B2B Buying Committee Benchmarks 2025 (zitiert Forrester State of Business Buying 2026) (cites Forrester State of Business Buying 2026)
• Google Search Central: Spam Policies (Scaled Content Abuse)
• Google Search Central: AI features and your website
• Google Search Central: Sitemap erstellen und einreichen (Limit 50.000 URLs) (build and submit a sitemap, limit 50,000 URLs)
• Webflow Hilfe: Dynamic content limits (Webflow Help)
• Webflow: Preise (Abruf 31.10.2026) (Webflow pricing, retrieved October 31, 2026)
• Webflow University: Quick Guide Content Editor Role