Quand Google AdSense indique que le fichier ads.txt est introuvable, alors qu’il est bien présent sur le serveur, le problème ne vient pas toujours du fichier lui-même.
Dans certains cas, Google arrive bien à accéder à /ads.txt, mais seulement après une redirection. Et si la chaîne de réponse ressemble parfois à ceci :
301 -> 200 301 -> 304
la détection AdSense peut devenir instable.
Le fichier est détecté un jour, puis quelques jours plus tard AdSense le signale à nouveau comme introuvable.
Voici comment diagnostiquer et corriger ce problème proprement avec Nginx.
Le symptôme
Le fichier ads.txt existe bien à la racine du site :
/var/www/comment-devenir-developpeur.com/ads.txt
Son contenu est correct :
google.com, pub-6395809416476409, DIRECT, f08c47fec0942fa0
Depuis un navigateur, l’URL semble fonctionner :
Pourtant, dans Google AdSense, le fichier peut apparaître comme introuvable après quelques jours.
La cause probable
En regardant les logs Nginx, on peut voir que Google passe bien avec l’agent suivant :
Google-adstxt
Mais il tombe parfois sur une redirection avant d’obtenir le fichier :
301 -> 200
ou :
301 -> 304
Une redirection 301 n’est pas forcément une erreur. Beaucoup de sites redirigent par exemple :
http://domaine.com
vers :
Mais pour ads.txt, il vaut mieux éviter toute ambiguïté. Google doit pouvoir obtenir directement le fichier, avec une réponse 200 OK, quelle que soit la variante appelée.
L’objectif
L’objectif est que ces 4 URL répondent directement en 200 :
http://comment-devenir-developpeur.com/ads.txt http://www.comment-devenir-developpeur.com/ads.txt https://comment-devenir-developpeur.com/ads.txt https://www.comment-devenir-developpeur.com/ads.txt
Au lieu d’avoir :
301 -> 200
on veut :
200
Vérifier la réponse actuelle
Avant de modifier la configuration, on peut tester les 4 variantes avec curl :
curl -I http://comment-devenir-developpeur.com/ads.txt curl -I http://www.comment-devenir-developpeur.com/ads.txt curl -I https://comment-devenir-developpeur.com/ads.txt curl -I https://www.comment-devenir-developpeur.com/ads.txt
Si une des réponses affiche :
HTTP/1.1 301 Moved Permanently
ou :
HTTP/2 301
cela signifie que le fichier passe par une redirection.
Pour AdSense, il est préférable que chaque variante retourne directement :
HTTP/1.1 200 OK
ou :
HTTP/2 200
Vérifier les logs Nginx
Pour voir comment Google récupère le fichier, on peut chercher les passages liés à ads.txt dans les logs :
sudo zgrep -h 'ads.txt' /var/log/nginx/access.log* | tail -n 100
On peut aussi filtrer spécifiquement Google :
sudo zgrep -h 'Google-adstxt' /var/log/nginx/access.log* | tail -n 100
Si les logs montrent des lignes avec 301, puis ensuite 200 ou 304, cela confirme que Google passe parfois par une chaîne de redirection.
Sauvegarder la configuration Nginx
Avant toute modification, il faut sauvegarder le fichier de configuration du site :
sudo cp /etc/nginx/sites-available/comment-devenir-developpeur.com.conf \ /etc/nginx/sites-available/comment-devenir-developpeur.com.conf.bak-ads-20260526-052147
Cela permet de revenir en arrière rapidement si besoin.
Modifier la configuration Nginx
Le fichier à modifier est :
/etc/nginx/sites-available/comment-devenir-developpeur.com.conf
L’idée est d’ajouter une règle spécifique pour /ads.txt dans chaque bloc serveur concerné.
Exemple pour le domaine sans www en HTTP :
server { listen 80; server_name comment-devenir-developpeur.com; root /var/www/comment-devenir-developpeur.com; location = /ads.txt { default_type text/plain; add_header Cache-Control "no-cache, must-revalidate"; try_files /ads.txt =404; } location / { return 301 https://www.comment-devenir-developpeur.com$request_uri; } }
Exemple pour le domaine avec www en HTTP :
server { listen 80; server_name www.comment-devenir-developpeur.com; root /var/www/comment-devenir-developpeur.com; location = /ads.txt { default_type text/plain; add_header Cache-Control "no-cache, must-revalidate"; try_files /ads.txt =404; } location / { return 301 https://www.comment-devenir-developpeur.com$request_uri; } }
Exemple pour le domaine sans www en HTTPS :
server { listen 443 ssl; server_name comment-devenir-developpeur.com; root /var/www/comment-devenir-developpeur.com; ssl_certificate /etc/letsencrypt/live/comment-devenir-developpeur.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/comment-devenir-developpeur.com/privkey.pem; location = /ads.txt { default_type text/plain; add_header Cache-Control "no-cache, must-revalidate"; try_files /ads.txt =404; } location / { return 301 https://www.comment-devenir-developpeur.com$request_uri; } }
Et dans le bloc principal HTTPS avec www, ajouter :
location = /ads.txt { default_type text/plain; add_header Cache-Control "no-cache, must-revalidate"; try_files /ads.txt =404; }
Pourquoi ajouter Cache-Control
La ligne suivante permet d’éviter qu’un cache garde une mauvaise réponse trop longtemps :
add_header Cache-Control "no-cache, must-revalidate";
Cela ne désactive pas complètement le cache, mais oblige le client ou le robot à revalider le fichier.
Pour un fichier aussi important que ads.txt, c’est une bonne précaution.
Tester la configuration Nginx
Après modification, il faut tester la configuration :
sudo nginx -t
Si tout est correct, Nginx doit répondre :
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Recharger Nginx
Si le test est bon, on peut recharger Nginx :
sudo systemctl reload nginx
Il ne faut pas redémarrer brutalement le serveur si ce n’est pas nécessaire. Un reload suffit généralement.
Vérifier les 4 variantes
Après le reload, refaire les tests :
curl -I http://comment-devenir-developpeur.com/ads.txt curl -I http://www.comment-devenir-developpeur.com/ads.txt curl -I https://comment-devenir-developpeur.com/ads.txt curl -I https://www.comment-devenir-developpeur.com/ads.txt
Le résultat attendu est :
HTTP 200
pour les 4 variantes.
Dans notre cas, le résultat final est :
http://comment-devenir-developpeur.com/ads.txt 200 http://www.comment-devenir-developpeur.com/ads.txt 200 https://comment-devenir-developpeur.com/ads.txt 200 https://www.comment-devenir-developpeur.com/ads.txt 200
Vérifier le contenu du fichier
On peut aussi vérifier que le contenu affiché est bien celui attendu :
curl https://www.comment-devenir-developpeur.com/ads.txt
Résultat attendu :
google.com, pub-6395809416476409, DIRECT, f08c47fec0942fa0
Combien de temps attendre dans AdSense
Même si le problème est corrigé côté serveur, Google AdSense ne met pas toujours son interface à jour immédiatement.
Il faut parfois attendre :
quelques heures à quelques jours
Le plus important est que, côté serveur, le fichier soit maintenant accessible proprement, sans redirection, avec une réponse directe en 200.
Conclusion
Quand AdSense indique que ads.txt est introuvable alors que le fichier existe, il faut vérifier plus que sa simple présence.
Les points importants sont :
- le fichier doit être à la racine du site ;
- le contenu doit contenir le bon identifiant éditeur ;
- l’URL doit répondre en 200 OK ;
- les variantes HTTP, HTTPS, avec et sans www, doivent être propres ;
- il vaut mieux éviter une chaîne 301 -> 200 pour /ads.txt ;
- un header Cache-Control: no-cache, must-revalidate peut éviter les états incohérents.
Dans ce cas précis, le problème probable venait de la redirection 301 rencontrée par Google avant d’obtenir le fichier. En servant /ads.txt directement en 200 sur toutes les variantes du domaine, la détection AdSense devient beaucoup plus fiable.