En bref. Applebot ajuste automatiquement sa fréquence d’exploration lorsqu’un site web ralentit ou renvoie des erreurs.

Définition : Applebot ajuste automatiquement sa fréquence d’exploration lorsqu’un site web ralentit ou renvoie des erreurs. Apple présente ce mécanisme comme un moyen de réduire l’impact de l’exploration sur les propriétaires de sites, sans documenter la fréquence, le seuil de déclenchement ni le délai de reprise.

Points clés

La documentation d’Apple sur Applebot indique que sa fréquence d’exploration s’ajuste automatiquement lorsqu’un site ralentit ou renvoie des erreurs.
Apple indique qu’Applebot met en cache les contenus explorés pour réduire les explorations inutiles.
Applebot ne tient pas compte de la directive crawl-delay dans robots.txt, selon cette même documentation.
La RFC 6585 définit le statut HTTP 429 Too Many Requests comme une limitation du débit après un nombre trop élevé de requêtes sur une période donnée.
La RFC 9110 définit le statut HTTP 503 Service Unavailable pour une surcharge temporaire ou une maintenance planifiée et autorise un en-tête Retry-After.

Que documente Apple sur l’ajustement automatique ?

Apple indique qu’Applebot est conçu pour réduire au minimum son impact sur les propriétaires de sites. L’exemple est explicite : lorsqu’un site ralentit ou renvoie des erreurs, la fréquence d’exploration d’Applebot s’ajuste automatiquement. Le même paragraphe précise qu’Applebot met en cache les contenus explorés pour réduire les explorations inutiles. La documentation ne donne aucune valeur chiffrée pour la fréquence d’exploration, le seuil ou le délai d’ajustement.

Cette description porte sur la réaction du robot d’exploration aux conditions observées sur le site. Elle ne définit aucun délai fixe pour un code d’erreur particulier. Apple mentionne aussi bien les réponses lentes que les réponses d’erreur : les journaux du serveur doivent donc conserver le temps de réponse et le code de statut associés à chaque requête d’Applebot.

Quelles réponses HTTP décrivent une surcharge ou une limitation du débit ?

Les normes HTTP nomment deux situations côté serveur qui peuvent correspondre aux erreurs évoquées par Apple. La RFC 6585 définit 429 Too Many Requests comme un nombre trop élevé de requêtes sur une période donnée. La réponse peut inclure un en-tête Retry-After qui indique le délai à respecter avant une nouvelle requête.

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

La RFC 9110 définit 503 Service Unavailable comme l’incapacité temporaire d’un serveur à traiter une requête en raison d’une surcharge ou d’une maintenance planifiée. Un serveur peut envoyer Retry-After pour suggérer le délai d’attente du client avant une nouvelle tentative. Ces normes définissent la signification des réponses ; la documentation d’Apple ne précise pas comment Applebot interprète une valeur Retry-After.

Le fichier robots.txt fixe-t-il la fréquence d’exploration d’Applebot ?

Apple indique qu’Applebot respecte les directives standard de robots.txt qui le ciblent, et son exemple exclut deux chemins d’URL :

User-agent: Applebot
Allow: /
Disallow: /private/
User-agent: *
Disallow: /not-allowed/

La même documentation d’Apple précise qu’Applebot ne tient pas compte de crawl-delay. Un groupe de règles dans robots.txt peut donc contrôler les chemins demandés par Applebot, tandis que la réaction documentée à un site lent ou renvoyant des erreurs reste un ajustement automatique de la fréquence d’exploration. En l’absence d’instructions propres à Applebot, Apple indique que le robot suit les instructions destinées à Googlebot lorsqu’elles sont présentes.

Comment un propriétaire de site peut-il examiner la situation ?

Apple explique qu’un agent utilisateur (user-agent) aide les webmestres à identifier le trafic des robots d’exploration et à obtenir des rapports précis à partir des journaux d’accès. L’analyse peut donc regrouper les requêtes vérifiées d’Applebot par code de statut et par temps de réponse, puis comparer ces observations aux périodes de surcharge ou de maintenance du site. Les normes HTTP définissent le sens des statuts 429 et 503, mais Apple ne publie aucune correspondance entre ces statuts et un intervalle précis entre les requêtes d’Applebot.

Termes associés

Questions fréquentes

Applebot tient-il compte de Crawl-delay ?

La documentation d’Apple indique qu’Applebot ne tient pas compte de crawl-delay. Les règles d’accès aux URL dans robots.txt restent utilisables pour les chemins dont l’exploration doit être interdite.

Un statut 429 ou 503 indique-t-il à Applebot exactement combien de temps attendre ?

Si vous renvoyez 429 ou 503, les normes HTTP décrivent la situation et autorisent une valeur Retry-After. Apple ne documente pas la manière dont Applebot applique cette valeur ; cette entrée n’attribue donc aucun délai d’attente à ces statuts.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Comment Applebot réagit-il lorsqu’un site web ralentit ou renvoie des erreurs ?