Lorsqu’il s’agit de créer des pages pour se classer dans la recherche organique, vous êtes généralement limité par l’un des quelques facteurs.
Vous pourriez être limité par les ressources, auquel cas vous ne pouvez vous permettre de créer des pages que pour quelques termes clés. Alternativement, vous pourriez être limité par le volume de recherche, auquel cas il y a très peu de termes qui valent même la peine de passer du temps à créer des pages.
De nombreuses marques se retrouvent dans une position où elles sont limitées par ces deux facteurs. Cela est particulièrement vrai pour de nombreuses marques B2B, qui cherchent à générer un volume de recherche organique à partir d’un large éventail de termes à faible volume, et qui n’ont pas nécessairement le temps de créer des pages uniques à classer pour chacun de ces termes.
Causal
Depuis un an environ, je travaille avec Causal , un outil de modélisation financière B2B qui se retrouve dans la situation ci-dessus. Les termes principaux tels que la modélisation financière sont suffisamment compétitifs pour qu’il ne soit pas réaliste de passer du temps à essayer de les classer, de sorte que les marques challenger comme Causal doivent penser à différentes façons d’atteindre leur client cible via le référencement.
L’un des arguments de vente de Causal est qu’il s’intègre parfaitement à de nombreuses plates-formes sur lesquelles les utilisateurs peuvent stocker des données financières. Il peut s’agir de plateformes comptables comme QuickBooks ou d’entrepôts de données comme Google BigQuery. De ce fait, les utilisateurs de ces plateformes qui souhaitent construire des modèles financiers constituent un bon public cible pour Causal.
Cependant, votre utilisateur typique de QuickBooks ne recherchera pas des termes tels que le modèle financier de QuickBooks . De manière plus réaliste, ils vont avoir un problème spécifique qu’ils veulent résoudre, comme comment calculer une mesure financière spécifique à partir de leurs données QuickBooks (pensez calculer la rétention des revenus nets dans les quickbooks ). L’hypothèse est qu’une fois que ces utilisateurs voient qu’ils peuvent utiliser Causal pour calculer et modéliser ces métriques spécifiques, ils pourraient rester et commencer à utiliser Causal pour modéliser d’autres choses également.
C’est bien beau, mais Causal s’intègre à des dizaines de ces plates-formes, et il existe potentiellement des centaines de mesures financières que leur public cible pourrait vouloir calculer. Aucun humain n’aurait jamais le temps de créer une page pour chaque combinaison de plate-forme et de métrique financière.
Le flux Web rencontre GPT-3
Pour accélérer les choses, tout en voulant toujours nous assurer que nous nous retrouvions avec des pages SEO utilisables et de haute qualité, nous avons utilisé une combinaison du CMS et du GPT-3 de Webflow.
Étape 1
Nous avons d’abord créé une catégorie CMS pour les métriques financières , et l’avons remplie avec une liste de métriques financières courantes (que nous avons en fait générées via GPT-3). Pour chaque métrique financière de la catégorie, nous avons de nouveau utilisé GPT-3 pour générer une brève description de la métrique et comment la calculer.
Étape 2
Nous avions déjà une catégorie CMS pour toutes les plateformes avec lesquelles Causal s’intègre ; tout ce que nous avions à faire ici était d’ajouter un indicateur pour les plates-formes pour lesquelles nous voulions générer ces comment calculer {metric} dans les pages {platform} pour.
Assembler les morceaux
Une fois que nous avons effectué les deux étapes ci-dessus, nous avons créé une autre catégorie appelée metric x platform . Celui-ci contenait toutes les combinaisons possibles des mesures financières que nous avons créées à l’étape 1 et de toutes les plates-formes que nous avons marquées à l’étape 2. Sur la base du nombre d’éléments CMS à chacune de ces étapes, nous nous sommes retrouvés avec environ 2 000 paires de plates-formes et de données financières. métrique.
Une fois que nous avons eu ces 2 000 paires, nous avons construit une page modèle que nous pourrions remplir avec les données de chaque paire. Le H1 de la page, par exemple, lit How to Calculate {metric.name} in {platform.name} . Plus bas sur la page, nous avons inclus la description et les étapes de calcul que GPT-3 avait écrites pour chacune des mesures financières, et avons également ajouté des informations sur la façon dont Causal s’est intégré à la plate-forme concernée et sur le fonctionnement de Causal.
Une fois que tout cela a été fait, nous avons mis les changements en ligne et avions 2 000 pages de référencement uniques prêtes à l’emploi, chacune ciblant un cas d’utilisation spécifique que les clients auraient pour Causal. Vous pouvez voir un exemple du type de page qui a été généré ici .
Résultats
Les pages sont en ligne depuis quelques mois maintenant et nous avons vu le trafic augmenter régulièrement.
Aucune des pages n’attire individuellement plus d’un utilisateur par jour, c’est pourquoi le faire manuellement aurait été une utilisation du temps incroyablement inefficace. Dans l’ensemble cependant, les pages attirent plusieurs centaines d’utilisateurs par semaine. Je considérerais cela comme un succès car :
Ce trafic est probablement entièrement incrémentiel La probabilité que l’un de ces utilisateurs ait trouvé Causal au cours de son parcours pour calculer la rétention des revenus nets dans QuickBooks (par exemple) est pratiquement nulle.
Ce sont des utilisateurs qui en ont besoin Un utilisateur qui saisit calculer la rétention des revenus nets dans les quickbooks est un utilisateur qui a un problème et recherche activement une solution. Pouvoir leur servir une page pertinente, qui met en évidence comment Causal peut résoudre leur problème, c’est vraiment tout l’intérêt du SEO.
Compétition
Étant donné que la barrière à l’entrée de la création manuelle de ces types de pages est si élevée et que le référencement programmatique/GPT-3 est encore assez rare, Causal a tendance à dominer les résultats de recherche pour les requêtes de la forme {metric} {platform} .
S’inspirer de Zapier
L’idée de ce projet me trottait dans la tête depuis longtemps et s’inspirait fortement de l’approche de Zapier en matière de référencement programmatique.
Qu’est-ce que Zapier ?
Zapier est une application d’automatisation qui vous permet de connecter différents services. Par exemple, vous pouvez être un utilisateur de Twitter et un utilisateur de Gmail, et souhaitez recevoir un e-mail dans votre boîte de réception Gmail chaque fois que quelqu’un tweete quelque chose contenant une certaine phrase. Zapier vous permet de le configurer facilement, sans avoir à écrire de code.
La stratégie SEO de Zapier
L’éclat de la stratégie SEO de Zapier était de voir qu’ils pouvaient générer efficacement des pages de destination pour chaque cas d’utilisation possible que quelqu’un pourrait avoir pour Zapier.
Pour ce faire, ils ont créé trois niveaux de pages de destination :
Niveau 1 : pour chaque application intégrée (par exemple /twitter) Il s’agirait de la page de destination la plus simple que vous auriez pour des applications telles que Twitter, Gmail, Google Calendar, Typeform, etc. Les pages de niveau 1 répertorient simplement quelques détails sur le applications, montre à quelles autres applications elles s’intègrent et certains flux de travail populaires entre ces applications. Les pages de destination de niveau 1 ciblent un petit nombre de termes à volume élevé ( intégration Twitter ).
Niveau 2 : pour chaque paire d’applications intégrées (par exemple, /twitter-to-gmail) Les pages de niveau connecter Twitter à Gmail ). Ces termes seront naturellement tous moins volumineux que les termes ciblés par les pages de niveau 1, mais seront également plus pertinents par rapport à l’intention du chercheur.
Niveau 3 : pour chaque flux de travail entre les paires d’applications avec lesquelles ils se sont intégrés (par exemple, rechercher-twitter-envoyer-vers-gmail) Ce sont les pages les plus spécifiques de la hiérarchie de Zapier et font référence à des manières très spécifiques dont un utilisateur pourrait vouloir envoyer données entre deux applications. Toutes les requêtes de recherche ciblées par ces pages seront très peu volumineuses, mais le fait que ces pages soient si pertinentes pour l’intention d’un utilisateur les rend incroyablement précieuses du point de vue du référencement.
Et pour combien d’efforts ?
Bien qu’il y ait sans aucun doute un certain niveau d’effort humain impliqué dans la rédaction de la copie qui entre dans toutes ces pages, le nombre de pages générées évolue beaucoup plus rapidement que l’effort requis. Par exemple, si Zapier avait 100 applications et que chaque application pouvait se connecter entre elles de 5 manières différentes, vous seriez en mesure de générer 29 800 pages de destination (100 + 100C2 + 5*100C2).
Et pour ces 29 800 landing pages, combien de travail y aurait-il eu ? Eh bien, pour les pages de destination de niveau 1 et 2, il vous suffirait d’écrire une copie dans votre CMS pour chaque application (c’est-à-dire 100 copies). Il est un peu plus difficile de calculer la quantité d’efforts nécessaires pour remplir toutes les pages de destination de niveau 3 avec une copie, mais cela ne devrait pas être déraisonnable si nous supposons que toutes les façons de connecter 2 applications ensemble ne sont pas complètement uniques (ce qui signifie que nous pouvons réutiliser copie).
Prendre du recul
En faisant abstraction pendant un instant, Zapier s’est rendu compte qu’ils avaient un moyen de générer un grand nombre de pages de destination pertinentes et personnalisées, à partir d’une petite quantité de copie pour chaque application à laquelle ils s’intégraient. Ils ont pu le faire parce que chacune des combinaisons d’applications avait un volume de recherche (avec des recherches comme connecter twitter à gmail ).
Ce que j’en ai tiré, et ce que j’essaie d’envisager à l’avenir, c’est où les marques sont capables de générer un nombre incroyablement élevé de pages de destination pertinentes simplement en examinant des combinaisons de pages de destination plus simples.
.gif)
