By Mehdi HassanWhat is a SaaS integrations page for?
A SaaS integrations page exists to answer one buying question fast: does this product work with the tools we already use? For many B2B buyers that question is a gate. If the answer is unclear, the evaluation stops before anyone books a demo, so the page carries more weight than its spot in the footer suggests.
It also does two quieter jobs. It shows momentum, because a growing, well-kept directory signals a product people build around. And it's an SEO surface: every integration is a page that can rank for searches like "[your product] HubSpot integration". That's why we treat it as part of the core site structure in our SaaS website design guide, not as an afterthought page.
How do you design a SaaS integrations page that buyers can scan?
Design the integrations directory for lookup, not browsing. Most visitors arrive with one or two tools in mind, so a search field and category filters at the top beat a wall of logos. The logo grid is the result list, not the page.
Lead with a one-line promise and search
A short headline ("Connect the tools your team already uses"), a search field and the total count of integrations. The count is a fact, so keep it accurate.
Add category filters
Group by job, not by partner type: CRM, data warehouse, messaging, identity, billing. Use the categories your buyers would search for, and keep them to 6–12.
Show cards with status
Each card has the partner logo, name, a one-line description of what the integration does and a status label: native, partner-built, via Zapier or beta.
Feature the integrations that close deals
Pin the 4–8 integrations sales mentions most at the top. These are usually the CRM, the data warehouse and the identity provider.
Close with a request path
A "Don't see your tool?" block with a request form and a link to your API docs, so a missing integration becomes a lead instead of an exit.
What should an integration detail page include?
An integration detail page should answer what the integration does, what data moves in which direction, how to set it up and who maintains it. Those four answers are what a technical evaluator needs, and they're also what makes each page unique enough to rank.
Section | What goes in it | Who it's for |
|---|---|---|
Header | Both logos, a one-sentence outcome, status label, primary CTA (connect or start trial) | Everyone |
Use cases | Two to four concrete jobs it does, written as outcomes | Champion |
Data and sync | Objects synced, direction, frequency, field mapping notes | Technical evaluator |
Setup | Numbered steps or a link to the docs article, plan requirements | Admin |
Maintainer and support | Built by you or the partner, where to get help | Admin, security |
Related integrations | Three to six in the same category | Browsers |
Keep marketing language out of the data section. An evaluator who reads "powerful sync" learns nothing; one who reads "contacts and deals sync both ways every 15 minutes" (if that's true for your product) can move on. Link setup steps to your docs rather than duplicating them, so they never drift out of date.
How should the integrations CMS be modeled?
Model integrations as one CMS collection with structured fields, and generate both the directory cards and the detail pages from it. That way marketing or partnerships can add a partner in minutes, and the directory, filters and detail page update together.
- Core fields: name, slug, logo, one-line description, category (reference), status (option), maintainer (option).
- Detail fields: outcome headline, use cases (rich text or repeating items), data synced, sync direction, setup steps or docs URL, plan requirement.
- SEO fields: meta title and description overrides, so you can write them by hand for the top partners.
- Relations: related integrations, related customer stories, related features.
- Flags: featured (for pinning), new (for a badge), hidden (for partners still in private beta).
Webflow CMS handles this well up to its collection limits, and a headless CMS with a Next.js front end handles very large directories, custom filtering and partner-submitted listings. We build both. The right choice depends on how many integrations you have now, how fast that grows and whether partners will edit their own listings.
For example, suppose you have 45 integrations and add three a month
For example, suppose a seed-stage SaaS company has 45 integrations and adds about three a month. One template for the directory and one for the detail page cover every partner. The team writes the copy for the eight featured integrations by hand and uses a shorter structured format for the rest, then improves those pages as search data shows which ones get traffic.
This is a hypothetical example to show the shape of the work, not a client result. The point is that the design effort sits in two templates and a content model, not in 45 pages.
How do integration landing pages help SEO?
Integration landing pages help SEO because they match specific, high-intent searches such as "[product] Salesforce integration" or "connect [product] to Slack". People searching that way are usually already evaluating you, so the traffic is small but valuable. The pages only rank if each one says something real and different.
- Write a unique intro and use cases for every page. Thin pages that only swap the partner name are the classic programmatic SEO failure.
- Use the partner name in the title, H1 and URL, for example /integrations/salesforce.
- Interlink: directory to detail, detail to related integrations, and feature pages to the integrations that power them.
- Keep hidden or deprecated partners out of the sitemap, and redirect removed pages to the category or directory.
- Add structured data where it fits. The SoftwareApplication type on schema.org is the usual starting point for describing the product.
Integrations also feed other pages. Your enterprise visitors check identity and security integrations next to your SaaS security page, and a vertical SaaS website often wins on the industry tools it connects to rather than the generic ones.
Should integrations live on your site or in an app marketplace?
Integrations should live on your own site even if you also have an in-product app marketplace. The marketplace serves existing users who are already logged in. The public directory serves prospects and search engines, and you control its design, copy and calls to action.
Pros
- A public directory ranks, converts prospects and supports sales conversations with a shareable link.
- You control positioning: which partners lead, how status is described and what the CTA is.
- One CMS can power both the site directory and in-app listings if you plan the fields together.
Cons
- Two surfaces can drift apart if no one owns updates.
- Partner-maintained listings need a review step so quality stays even.
- Large directories need real search and filtering, which is more build work than a static page.
If you're planning a broader SaaS website redesign, fold the integrations directory into the same content model rather than bolting it on later. It's much cheaper to design the templates once, alongside the feature and customer story templates they link to.
What does a good integrations page look like in practice?
A good integrations page is fast to search, honest about status and links every card to a detail page that answers the technical questions. The strongest ones we see on live SaaS sites share a handful of habits, which we break down further in our SaaS website examples.
- Search is visible on load and filters by name and category at once.
- Each card has a plain one-liner, not the partner's own tagline.
- Status labels are consistent and explained once at the top.
- Detail pages use the same layout, so evaluators know where to look.
- There's a clear path for missing tools: request form, API docs or both.
- The page is linked from the main navigation or the product menu, not only the footer.
If you're comparing studios for this kind of build, our guide to choosing a SaaS website design agency lists the questions that reveal whether a team can model content, not only design screens. Ask to see a CMS structure, not only finished pages.
