SaaS integration pages when you only have a few integrations

At some point in every evaluation, your buyer opens your integrations page to check one thing: does this work with the tools we already run?

Integrations can decide which vendor makes the shortlist. In interviews published by Pandium, which sells integration infrastructure, one interviewee said prospects tell her company it has gone to the top of their vendor list because it has an integration the others lack.

Most advice about integration pages assumes you have hundreds or thousands of integrations. Early-stage SaaS companies usually don't. If you only have a handful of integrations, you don't need a giant directory. You need a few useful pages that explain exactly what happens when your product connects to another tool.

An integration page isn't there to tell Google that you integrate with HubSpot. It's there to help a HubSpot user decide whether your integration will actually work for them.

Integration pages are one of the pages worth prioritizing when you're deciding what to build on a small SaaS site, and an early-stage SaaS SEO guide covers the others.

Say How It Connects

First, tell buyers how the integration works. There are three common setups:

• Native. You built the connection, it runs inside your product, and you maintain it.
• Through a third-party connector. It runs through Zapier, Make, Workato or a similar tool. The customer usually sets it up and pays for the connector.
• Custom, through your API. The customer's own developers build it.

Put the setup type near the top of the page. In the same Pandium interviews, an operator described buying a tool listed as integrating with her CRM, then finding during setup that it ran through a third-party connector. She said the delay between the two systems cost her team about $200,000 in pipeline, and they were switching platforms as a result. A simple "via Zapier" label would have made that clear before she signed.

A connector-based integration still deserves a page if customers use it. Zapier's publishing guide recommends that app makers publish help documentation for their Zapier integration on their own website. Label it clearly and link the setup steps.

Say What Happens When It Connects

An integration page isn't a list of logos. It's an expectation-setting page.

In the Pandium interviews, one team bought a billing tool that integrates with HubSpot and learned that, in the operator's words, "integration means one field email address pops into HubSpot." Payment status, role and product usage never arrived, and nothing flowed back the other way.

So every integration page should answer four questions.

• What moves. Name the records and fields: contacts, deals, invoices, events.
• Which direction. One way, and which way, or both.
• How often. In real time, on a schedule, or when someone clicks a button.
• What it doesn't do. The limits a buyer would otherwise find during setup.

Don't skip the fourth one. Being honest up front means you won't lose customers or damage your brand later because they expected something the integration doesn't do.

Apollo's HubSpot integration overview is a good model. It explains that there are two versions of the integration, says plainly that the enrichment version doesn't include full two-way sync, and points readers to the CRM version if they need it. A buyer reading that knows which one to install before they start.

Show the Task It Does

Then show one task from start to finish. A founder on r/SaaS described rewriting landing pages around the moment in a demo when a customer sees one real task happen. That's what your integration page should recreate: show what the task looked like before and what it looks like now.

Use-case pages take the same idea one step further, with one task written for a whole customer segment. Give each segment one main benefit and two or three secondary ones. If the main benefit comes out the same for every segment, the segments need redrawing.

Explain the Access It Needs

Some integrations ask for access to systems a buyer guards closely, such as billing, email or the CRM. For those, the integration page carries most of the trust work.

Before you send anyone to the other product's consent screen:

• Explain in plain words what you can read and what you can change.
• Say in one line what you never touch.
• Show the screen they'll land on after connecting, using sample data.
• Make it obvious how to disconnect.

Keep your page consistent with the consent screen. If the screen says your product can read and write their data, don't describe it as read-only anywhere on the page.

Some buyers won't be comfortable connecting a third-party tool to their billing system. That's okay. Be clear about who the integration is designed for rather than trying to overcome every objection.

Show How to Set It Up

If customers can install the integration in different ways, show the common setup paths on the page. If there are separate instructions for Google Tag Manager, Shopify, or a CMS plugin, link to each one and surface any known setup issues.

Once your integration page is live, consider listing the integration in the partner's marketplace. Treat the marketplace as a distribution channel, not a replacement for your own page: your website should explain the integration in full, while the marketplace puts it in front of users already looking for compatible tools.

Keep the Page Honest

An integrations page is a list of promises, and it goes out of date without anyone noticing.

Fleet dealt with this in public. An issue in its GitHub repository listed broken links on the integrations page and descriptions of capabilities the documentation didn't support, after multiple customers had asked what the entries meant. The team fixed the links and rewrote the unclear descriptions.

Give every integration an owner and review the list regularly. Your support team will usually know which ones are broken before you do, so ask them first.

Give Pages Only to the Integrations Buyers Ask About

Give dedicated pages to the integrations that come up most often in sales calls and support tickets. Keep the rest as logos on your integrations page.

An integration earns its own page when all three of these are true.

• Prospects mention the tool before you do. If it only comes up when you list it, the page will attract people who don't use it.
• Customers use the integration. Check the usage data. If nobody has turned it on yet, it isn't ready for a page of its own.
• You can describe one task it does in a sentence. For example: "When you close a deal in HubSpot, we set up the new customer's account for you." If you can't say what it does that simply, fix the integration before you write the page.

Where Templates Go Wrong

Don't create integration pages just because they are an SEO page type. Create them because each integration has something specific to say.

Templates cause trouble when the only thing that changes from page to page is the tool's name. Google's spam policies list creating substantially similar pages that are closer to search results than a browsable hierarchy as a doorway tactic. Google's March 2024 update extended its scaled content policy to cover pages produced at scale to manipulate rankings, whether a person, a machine or both produced them.

Here's a quick test. Delete the tool's name from one of your integration pages and read it back. If it could describe any integration you have, it's a template with nothing in it. What syncs, the task, the access and the setup steps are different for every integration. That's what makes each page useful to a buyer.

Link each integration page from relevant product pages and from your integrations grid. Add it to your sitemap when it goes live.

When to Wait

Sometimes the answer is to hold off.

If none of your integrations has active users yet, don't build pages for all of them. Talk to five customers about which tools they'd want to connect first. That conversation will tell you which integration is worth prioritizing.

If you can't describe one task an integration does, the page will expose that. Fix the integration, or the positioning behind it, first.

And if an integration is broken, take it off the list before you write anything about it. An integration page can't manufacture demand for an integration your buyers don't want.

Before You Publish

Before publishing an integration page, make sure a buyer can answer these questions:

• How does it connect?
• What data moves?
• In which direction?
• How often?
• What doesn't it support?
• What does the customer actually accomplish?
• What permissions does it need?
• How does setup work?
• How does the customer disconnect it?

Want to know which of your integrations deserve their own page? That's one of the things we look at in the free SaaS SEO audit, and deciding which pages to build first is a core part of our content marketing work. The audit is done by hand, in 48 hours, and there's no pitch attached to it.

Common Questions

What Should a SaaS Integration Page Include?

The nine answers in the checklist above. The two easiest to forget are what the integration doesn't do and how to disconnect it.

How Many Integrations Do We Need Before Building Integration Pages?

One is enough if buyers ask about it and customers use it. The number matters less than whether each page has something specific to say.

Should We Build a Page for an Integration That Runs Through Zapier?

Yes. Label it as a Zapier integration, and link Zapier's setup steps alongside your own.

Should We List Integrations We're Still Building?

Only if the page says clearly that they're in development. Never write a page targeting an integration you don't have.

Where Should Integration Pages Live on the Site?

In your main site structure, at a path such as /integrations/hubspot, where your product pages can link to them.

Do We Need to List on the Partner's Marketplace?

Once your own page is live and the integration is stable, it's worth doing. Expect the marketplace review to question every permission you request.

Kehinde Akindele

Founder, Derive DE · Upwork Top Rated, 100% Job Success

I run Derive DE, a B2B SaaS marketing studio in Lagos working with early-stage SaaS teams across the US, UK, and Africa. I plan the work and I do the work.

Connect on LinkedIn ↗

← All posts