A Public Integrations Page That Works as a Directory

Think of the last time you searched for a tool that would work with something you already use. You probably typed the other tool's name, plus a word like "integration", and clicked the first result that looked like it would give you a straight answer. The page that wins that click is rarely the one with the most logos. It is the one that answers the question: does it work, how, and what do I do next?

A public integrations page, done well, behaves like a small directory. It lets people browse by category, search by name, read what each connection does and begin setting it up. This guide covers how to build one, from structure to maintenance to measurement. It deals with the page as a whole, where a separate guide on this site covers how to word each individual entry.

What the page is for

An integrations page has three audiences, and a good one serves them all.

Evaluators. People deciding whether to try or buy. They want to know whether your product connects to the tools they depend on.

Existing users. People who want to extend what they have. They want setup steps and limits.

Searchers and assistants. People and software that arrive from a query about a specific tool and need a precise answer.

The page also works for you: it expresses the shape of your ecosystem, shows your commitment to openness and creates entry points from search.

Structure: a hub and spokes

A single page cannot hold everything, and should not try. A hub-and-spoke structure works well.

The hub is the main integrations page. It offers an overview, a way to find a specific tool and links to details.

The spokes are individual pages for each significant integration. They hold what a user needs: a description, how it works, setup steps, limits, examples and support.

Supporting pages include the developer documentation for the open interface, a status page and guidance for requesting or building new connections.

Link the layers both ways, so that a person arriving at a spoke can return to the hub and find neighbouring tools.

The hub page

A strong hub has a few elements.

• A plain headline and introduction: what the page lists, in a sentence or two, and what types of integration exist.
• Search: a box that finds integrations by name and by job. Many visitors arrive with a single tool name in mind.
• Categories: accounting, messaging, storage, calendars, forms and so on. Use the words your users use. A category list also helps readers who do not know what they want.
• Filters, where the list is long: by type of connection, direction of data, plan or status.
• Cards or rows for each integration, with the name, one-line job, type and status.
• A "most used" or "recommended" section, based on real usage, if you have it.
• A request path: a clear route for asking for a connection that does not exist.
• A developer section: a short pointer to the open interface and documentation for those who want to build their own.
• A last-updated date.

Keep the page light. It should load quickly and work on a phone.

The spoke pages

For each important integration, write a page that stands on its own. Include:

• A heading with the tool's name and what the connection does.
• The job in a sentence, and then a short account of how it works.
• What data moves, in which direction and how often.
• Setup: numbered steps with screenshots, and an estimate of the time required.
• Requirements: plans, permissions, versions and accounts needed on each side.
• Limits: what is not covered. Honesty here saves support requests.
• Examples: a typical use, perhaps with a short worked scenario.
• Troubleshooting: the three most common problems and their fixes.
• Support: where to go for help.
• Status and last checked date.
• Related integrations, in the same category.

Write each page so that it answers the query "[your product] and [tool]" fully. That is the search that will bring people to it.

Search and findability

Both internal and external search matter.

Internal search should be forgiving: handle misspellings, alternative names and common abbreviations. If a tool has changed its name, support the old one.

External search depends on clear, descriptive pages.

• Use the tool's actual name in the title, heading and first paragraph.
• Write the page title and description so that they make sense in a results list.
• Use headings and lists, which help both readers and search engines.
• Avoid putting key content in images or in scripts that crawlers cannot read.
• Link between related pages.
• Include the data that assistants need: what it does, direction, limits, status.
• Keep each page unique. Do not duplicate the same text across dozens of pages with only the name changed; write what is true of each.

Showing health and status

A directory is more useful when it tells the truth about its entries.

• A status marker on each: working, degraded, deprecated, retired, beta.
• A last-checked date per integration.
• A link to a changelog for the connection.
• A notice on affected pages if a connection has a known problem.
• Clear retirement: if an integration is removed, leave a page that says so, explains why and suggests alternatives, rather than deleting it.

This level of honesty builds trust and reduces support load. See the guide on compatibility and deprecation notices for handling changes.

Accessibility

The page should be usable by everyone.

• Provide text alternatives for logos and icons: the tool's name, not "logo".
• Make search, filters and cards operable by keyboard, with visible focus.
• Do not rely on colour alone for status. Use words and shapes beside colour.
• Ensure sufficient contrast and readable text sizes.
• Use proper headings and landmarks, so that screen reader users can navigate.
• Test on a phone and with browser text enlarged.

Following accessibility guidance such as the Web Content Accessibility Guidelines improves the experience for all users and tends to improve findability.

Community and third-party integrations

If others can build connections, a directory can include them.

• Define the process: how to submit, what is checked and who reviews.
• Label clearly who built and maintains each one.
• Set minimum standards: documentation, a contact, a way to report problems.
• State your level of support, which may be none.
• Review periodically, and retire the unmaintained.
• Give credit to contributors.

A healthy community section extends your reach without pretending that you built everything.

Keep it current: ownership and routine

Directories decay without care.

• One named owner, with a deputy.
• A schedule: test each integration at least quarterly, and after major releases on either side.
• Automated checks, where possible, that exercise the connections and flag failures.
• A change log for the page.
• A feedback link on each page: "Is this correct?"
• Review requests and use them to prioritise new connections.
• Remove or update dead entries promptly.

If there is a single rule, it is this: a smaller list that is accurate beats a larger one that is not.

Measuring what it does

Treat the page as a product with its own measures.

• Visits, and from where: search, direct, in-product.
• Search terms used on the page, especially those with no results. They show missing integrations.
• Clicks from hub to spoke, and from spoke to setup.
• Completion of setup, if you can measure it.
• New users who first arrived on an integration page, and their activation and retention compared with others.
• Support questions about integrations, before and after improvements.
• Requests for new connections.

Use the results to decide what to write, build and fix next.

A worked example

A small company has a single page of logos headed "Integrations". The team rebuilds it as a directory. The hub gets a search box, eight categories and cards with name, job and status. They write spoke pages for the six integrations with the most usage, each with setup steps, limits and a last-checked date. The remaining ten stay as short cards, with a one-line description and a link to a guide.

They add a request form and a pointer to the open interface for people who want to build their own. They run a script each week that exercises the main connections and flags failures to the page's owner.

In the first quarter, the hub receives 3,200 visits, and 38 per cent of them use search. The most common failed search is for a tool they do not support; they build that integration the following month. Spoke pages for the top three integrations rank in search for queries such as "[tool] and [product]", and bring in about 180 new sign-ups a month. Integration-related support questions fall by a quarter. When one integration breaks after the other company changes its interface, the status marker turns amber the same day, and users are told before they ask.

Questions makers ask

Is it worth the effort for a few integrations? Yes. Even three well-explained connections can bring qualified visitors.

Should I rank integrations by popularity? You can, if it helps users. Be clear that it is a usage ranking, not a quality judgement.

Do I need a separate developer portal? If you have an open interface, a dedicated documentation site helps. Link it from the integrations hub.

What if I have no integrations yet? Publish an honest page that says so, explains your plans and invites requests.

Summary

A public integrations page works best as a small directory: a hub with search, categories and cards, linked to individual pages that hold setup steps, limits and examples. Show status and last-checked dates on every entry, write each page for the specific query that will bring people to it and make everything accessible. Define a clear process for community connections, give the page an owner and a testing routine and measure visits, searches, setups and the users it brings. Accuracy keeps it useful.