When it comes to building pages to rank in organic search, you're usually limited by one of a few factors.

You might be limited by resource, in which case you can only afford to build pages for a few key terms. Alternatively, you might be limited by search volume, in which case there are very few terms that are even worth spending human time building pages for.

A lot of brands find themselves in a position where they're limited by both of these factors. This is particularly true for many B2B brands, who are looking to drive organic search volume from a wide range of low-volume terms, and who don't necessarily have time to build unique pages to rank for each of those terms.

Cue Causal

For the past year or so, I've been working with Causal, a B2B financial modelling tool which finds itself in the situation above. Head terms like financial modelling are competitive enough that it's not realistically worth spending time trying to rank for them, so challenger brands like Causal have to think of different ways to reach their target customer through SEO.

One of Causal's selling points is that it integrates nicely with a lot of platforms where users might store financial data. These could be accounting platforms like QuickBooks, or data warehouses like Google BigQuery. Because of this fact, users of these platforms who want to build financial models make up a good target audience for Causal.

Your typical QuickBooks user isn't going to search terms like quickbooks financial model though. More realistically, they're going to have a specific problem which they want to solve, like how to calculate a specific financial metric from their QuickBooks data (think calculate net revenue retention in quickbooks). The hypothesis is that once these users see they can use Causal to calculate and model out these specific metrics, they might stick around and start to use Causal to model other things too.

This is all well and good, but Causal integrates with dozens of these platforms, and there are potentially hundreds of financial metrics that their target audience might want to calculate. No human would ever have to time to build a page for each and every combination of platform and financial metric.

Webflow Meets GPT-3

To speed things up, whilst still wanting to ensure that we ended up with high-quality, usable SEO pages, we used a combination of Webflow's CMS and GPT-3.

Step 1

We first created a CMS category for financial metrics, and populated this with a list of common financial metrics (which we in fact generated via GPT-3). For each financial metric in the category, we used GPT-3 again to generate a brief description of the metric, and how to calculate it.

Step 2

We already had a CMS category for all of the platforms which Causal integrates with; all we had to do here was to add a flag for the platforms which we wanted to generate these how to calculate {metric} in {platform} pages for.

Putting the pieces together

Once we'd done the two steps above, we created a further category called metric x platform. This contained all the possible combinations of the financial metrics we created in step 1 and all the platforms we marked out in step 2. Based on the number of CMS items in each of these steps, we ended up with around 2,000 pairs of platforms and financial metrics.

Once we had these 2,000 pairs, we built a template page that we could populate with data from each pair. The page's H1 for example read How to Calculate {metric.name} in {platform.name}. Further down the page we included the description and calculation steps which GPT-3 had written for each of the financial metrics, and also added some information about how Causal integrated with the relevant platform, and how Causal works.

Once all this was done we pushed the changes live and had 2,000 unique SEO pages all ready to go, each targeting a specific use case that customers would have for Causal. You can see an example of the sort of page that was generated here.

Results

We've had the pages live for a couple of months now, and have seen traffic steadily grow.

None of the pages individually bring in more than 1 user a day, which is why doing this manually would have been an incredibly inefficient use of time. In aggregate though, the pages bring in several hundred users a week. I'd consider this a success as:

• This traffic is likely wholly incremental
  ‍The chance of any of these users having found Causal during their journey to calculate net revenue retention in QuickBooks (for example), is virtually 0.

• These are users in their hour of need
  ‍A user typing in calculate net revenue retention in quickbooks is a user who has a problem, and is actively looking for a solution. Being able to serve them a relevant page, which highlights how Causal can solve their problem, is really the whole point of SEO.

Competition

Because the barrier to entry of creating these sorts of pages manually is so high, and programmatic/GPT-3-driven SEO is still fairly uncommon, Causal tends to dominate the search results for queries of the form {metric} {platform}.

Taking Inspiration from Zapier

The idea for this project had been around in my head for a long time, and was heavily inspired by Zapier's approach to programmatic SEO.

What is Zapier?

Zapier is an automation app that lets you connect together different services. For example, you might be a Twitter user, and a Gmail user, and want to receive an email to your Gmail inbox each time someone tweeted something containing a certain phrase. Zapier lets you set this up easily, without having to write any code.

Zapier's SEO strategy

The brilliance of Zapier's SEO strategy was to see that they could efficiently generate landing pages for every possible use case someone might have for Zapier.

They did this by building three tiers of landing pages:

• Tier 1: for each app they integrated with (e.g. /twitter)
  ‍This would be the simplest landing page which you'd have for apps like Twitter, Gmail, Google Calendar, Typeform etc. The tier 1 pages simply list some details about the apps, shows which other apps they integrate with, and some popular workflows between those apps. Tier 1 landing pages go after a small number high volume terms (twitter integration).
• Tier 2: for each pair of apps they integrated with (e.g. /twitter-to-gmail)
  ‍Tier 2 pages are more specific than tier 1 pages, as they target search terms which contain pairs of apps (e.g. connect Twitter to Gmail). These terms will naturally all be lower volume than the terms targeted by tier 1 pages, but will also be more relevant to the searcher's intent.
• Tier 3: for each workflow between pairs of apps they integrated with (e.g. search-twitter-send-to-gmail)
  ‍These are the most specific pages in Zapier's hierarchy, and refer to very specific ways in which a user might want to send data between two apps. All of the search queries targeted by these pages will be very low in volume, but the fact these pages are so hyper-relevant to a user's intent makes them incredibly valuable from an SEO perspective.

And for how much effort?

Whilst there is no doubt some level of human effort involved in writing the copy that goes into all these pages, the number of pages generated scales far more quickly than the effort required. For example, if Zapier had 100 apps, and each app could connect with each other app in 5 different ways, you'd be able to generate 29,800 landing pages (100 + 100C2 + 5*100C2).

And for these 29,800 landing pages, how much work would there have been? Well, for tier 1 and 2 landing pages, you'd only need to write copy in your CMS for each app (i.e. 100 pieces of copy). It's a little more difficult to calculate the amount of effort needed to populate all the tier 3 landing pages with copy, but it shouldn't be unreasonable if we assume that not every way of connecting 2 apps together is completely unique (meaning we can reuse copy).

Taking a step back

Abstracting for just a moment, Zapier realised that they had a way to generate a large number of relevant, tailored landing pages, from a small amount of copy for each app they integrated with. They were able to do this because each of the combinations of apps had search volume (with searches like connect twitter to gmail).

What I took from this, and what I'm trying to consider going forward, is where else brands are able to generate staggeringly large numbers of relevant landing pages simply from looking at combinations of simpler landing pages.

• If you think you have any ideas where this sort of approach might be useful, I'd love to chat about it.

‍