Sans aucune objectivité, j’affirme que le SEO est certainement l’un des métiers les plus passionnants tant les manières de l’aborder sont différentes. Toutefois, il y a un dénominateur commun à toutes les expériences que pourraient conter les consultants et autres noms de poste sympas finissant par « SEO » : les relations avec les autres métiers.

Un premier exemple me vient en tête, tirée de mon expérience de SEO en agence web :

« On met le site en ligne demain ! »
« … ce demain ? »
« Oui ! Les dév viennent de finir ! »
« Ça va pas être possible non. »
« On n’a pas le choix, le client nous court après depuis deux semaines. On est déjà en retard en plus. »

L’argument selon lequel le « client attend » est certainement l’un des plus difficiles à combattre car souvent le client attend pour de bonnes raisons. Du moins, lorsque la date de mise en ligne d’un site est dépassée ce qui, avouons-le, arrive régulièrement.

Situation idéale : le SEO est « prêt »

Partons du principe que le site est prêt d’un point de vue SEO, que toutes les actions qui devaient être menées l’ont été. Qu’est-ce qui pourrait repousser le choix de la date et de l’heure de mise en ligne ?

  • Le trafic naturel sur le site.
  • Un besoin d’exploration important de Googlebot constaté.

À l’inverse du référencement payant qui peut être interrompu sur une période définie, le référencement naturel ne permet pas autant de libertés. Et quand bien même un code de réponse 503 pourrait fonctionner le temps du déploiement de la nouvelle infrastructure, il n’en demeure pas moins que les sessions SEO seront impactées de même que l’exploration de Googlebot.

Une heatmap : de multiples interprétations

Alors pourquoi ne pas déployer une mise en ligne au moment où les statistiques de trafic / logs sont au plus bas ?

Bâtir une heatmap pour isoler les périodes de moindre affluence permet simplement de minimiser les risques, de disposer d’un argument solide autant auprès d’un Chef de projet que d’un client.

Dans le cas d’une refonte, on observe généralement un besoin d’exploration plus important dans les jours qui suivent.

refonte-b

On sait que Google accorde une attention particulière à la capacité du site d’encaisser autant de robots au même moment. Un brevet est notamment consacré sur ce sujet : Limiter les requêtes des crawlers web sur un serveur (disponible en anglais uniquement).

Un système pour équilibrer la capacité de charge d’hôtes web entre plusieurs robots d’exploration concurrents d’un moteur de recherche reçoivent à partir d’une pluralité de robots d’exploration, un flux de demandes de capacité pour une pluralité d’hôtes web. Chaque hébergeur dispose d’un serveur web associé avec une capacité de charge maximale – représentant le nombre maximal d’unités de demandes de documents que les robots d’exploration du Web peuvent collecter au cours de chaque unité de temps (ex. nombre maximum de requêtes par minute). Pour chaque paire entre le crawler web requérant et l’hôte web demandé, le système crée un bail entre l’hébergeur web et le robot de recherche web. Le bail comprend une identité du robot d’exploration Web, une identité du serveur, une capacité de charge allouée au robot d’indexation et une capacité de charge allouée à l’hôte web. à l’heure prévue.

brevet web host

L’affluence combinée avec les utilisateurs a évidemment un impact plus important. La heatmap peut éventuellement permettre d’identifier une période creuse et plus ou moins prolongée au niveau des sessions utilisateurs et qui pourrait donc bénéficier à l’exploration des robots.

Bâtir la heatmap avec R Studio

Bâtir la heatmap est relativement simple et exigera les packages suivants :

  • googleAnalyticsR
  • dplyr
  • tidyr
  • highcharter

Avant d’exécuter le code, vous devrez récupérer l’identifiant de la vue Analytics pour laquelle vous souhaitez analyser les données :

id vue analytics

Le code en lui-même a été co-écrit par Mark Edmondson, Tim Wilson, Donal Phipps et Dr. Michael Levin.

# Start by loading the libraries we'll want to use.
library(googleAnalyticsR)
library(dplyr)
library(tidyr)
library(highcharter)

# Set the view ID that we'll be using. You can get the view ID for a specific view
# that you have access to by logging into the Google Analytics Query Explorer at
# https://ga-dev-tools.appspot.com/query-explorer/. It's the "ids" value.
view_id <- XYZ

# Authorize Google Analytics
ga_auth()

# Pull the data. This is set to pull the last 400 days of data.
gadata <- google_analytics_4(view_id, 
                             date_range = c(Sys.Date() - 400, Sys.Date()),
                             metrics = "sessions", 
                             dimensions = c("date","hour"),
                             max = -1)

# Added a column to the data with the weekday.
gadata$weekday <- ordered(weekdays(gadata$date, FALSE), 
                          levels = c("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"))

# Subset the data to just be the weekday, hour of the day, and sessions. (This
# means we're getting rid of the "date" column)
heatmap_data <- select(gadata, weekday, hour, sessions)

# Summarize the data by weekday-hour
heatmap_sums <- group_by(heatmap_data, weekday, hour) %>%
  summarise(sessions = sum(sessions))

# Now, "spread" the data out so it's heatmap-ready
heatmap_recast <- spread(heatmap_sums, hour, sessions)

# Make this "data frame" into a "matrix"
heatmap_matrix <- as.matrix(heatmap_recast[-1])

# Name the rows to match the weeks
row.names(heatmap_matrix) <- c("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")

# Generate the heatmap of weekdays per hour
hchart(heatmap_matrix, type = "heatmap")

On obtient la heatmap suivante :

heatmap r studio

Maintenant, vous détenez un solide contre argument pour faire valoir votre position dans les discussions.

Qu’est-ce que vous en pensez ?

Publié dans R