Sites générateurs de revenus
Gardez boutique, site de réservation, produit par abonnement ou site de prospects sous contrôles externes récurrents.
Surveillance de disponibilité pour les sites SEO et commerciaux
Surveillez l’URL publique du projet, examinez disponibilité et réponses sur 30 jours et enquêtez sur les contrôles HTTP échoués. Retrouvez incidents et e-mails admissibles dans votre travail SEO.
Configurer la surveillance de disponibilité
Activez les contrôles récurrents de l’URL publique du projet Screpy. Choisissez une cible utile aux visiteurs avant de fixer la fréquence.
- Chaque projet surveille une URL HTTP ou HTTPS, pas une liste de points de terminaison.
- Les paramètres contrôlent l’activation, un intervalle de 1–60 minutes et une adresse de notification facultative.
- Les contrôles planifiés nécessitent une offre payante active et compatible ; les intervalles par défaut varient.
- L’inactivité de l’équipe allonge les intervalles ; après 30 jours sans activité, les contrôles cessent.
- Le dernier contrôle indique la fraîcheur ; l’intervalle configuré ne garantit pas une heure exacte d’exécution.
example.com60 s
Comprendre le taux de disponibilité
Consultez la proportion de contrôles réussis sur les 30 derniers jours. Lisez le taux avec le nombre de contrôles et leur dernière date.
- Le taux correspond aux contrôles réussis divisés par tous les contrôles enregistrés, multipliés par 100.
- L’état actuel provient du dernier contrôle terminé dans cette période.
- Sans contrôles enregistrés, les données sont indisponibles, et non égales à 100 %.
- Ce taux repose sur des échantillons ; il ne se convertit pas directement en minutes de panne ou en SLA pondéré par durée.
Disponibilité
93,8 %503200
Suivre les temps de réponse
Repérez les réponses lentes et les échecs répétés dans le graphique. Une URL accessible peut néanmoins répondre lentement.
- Le graphique utilise jusqu’à 160 contrôles récents sur 30 jours ; la largeur d’écran détermine la partie visible.
- La tendance moyenne cinq contrôles ; la réponse moyenne utilise les contrôles réussis des 30 jours complets.
- Ces durées mesurent la latence HTTP, pas le chargement complet, les Core Web Vitals ou un parcours visiteur.
Temps de réponse
240 msExaminer les statuts HTTP
Consultez les huit derniers contrôles : état, date, code HTTP et réponse. Comparez-les au comportement attendu de l’URL publique.
- HTTP 200–399 est disponible ; les autres réponses HTTP indiquent une indisponibilité. Expiration du délai et erreur restent distinctes.
- Les redirections ne sont pas suivies : un résultat 3xx ne valide pas la destination.
- Les contrôles utilisent HEAD, puis GET sur 405 ou 501 ; une erreur de connexion peut ne pas fournir de code HTTP.
- Un état disponible ne valide ni contenu, ni formulaire, ni achat ; une page d’erreur HTTP 200 peut aussi être disponible.
Statut HTTP
200GET /HTTP/2 200Examiner les incidents de panne
Suivez l’incident du premier échec jusqu’à un contrôle réussi. La recherche de la cause reste une enquête distincte.
- Le premier échec ouvre un incident, les suivants le mettent à jour, le premier succès le résout.
- Le tableau de bord affiche les nombres d’incidents ouverts et résolus toutes périodes confondues, puis les cinq derniers avec état, début et détails.
- Les dates reflètent les contrôles, pas le début exact entre échantillons ; certaines pannes brèves peuvent passer inaperçues.
Période
12 min503200
Recevoir des e-mails de panne
Envoyez les avis admissibles aux membres et à une adresse supplémentaire facultative. L’incident est enregistré avant de devenir admissible à un e-mail.
- Un échec ultérieur du même incident peut déclencher un e-mail pour des codes pris en charge, comme 404, 500 ou 503.
- Délais expirés, erreurs de connexion et codes non pris en charge sont enregistrés sans déclencher ces e-mails.
- Chaque projet a des limites distinctes d’un e-mail de panne et d’un e-mail de rétablissement par 24 heures.
- Le rétablissement nécessite un incident déjà notifié et non supprimé ; la durée enregistrée ne prouve pas la panne exacte vécue par les visiteurs.
!
Projetexample.com
ExamenLire la disponibilité via SEO MCP
Demandez à un assistant connecté d’expliquer les résultats enregistrés d’un projet accessible. La date distingue une observation existante d’un nouveau contrôle.
- SEO MCP renvoie état sur 30 jours, taux, moyenne des contrôles réussis et dernier contrôle.
- Jusqu’à 160 enregistrements récents comportent état, réponse et date, sans codes HTTP ni incidents.
- La lecture ne lance aucun contrôle, ne diagnostique ni ne corrige une panne ; les résultats absents restent indisponibles.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Ajouter la disponibilité aux rapports SEO
Partagez les observations dans un rapport enregistré pour un client ou une équipe. Un instantané diffère d’un écran de surveillance en direct.
- Le widget comprend statistiques de 30 jours, contrôles récents et incidents chevauchant la période du rapport.
- Le nombre d’incidents peut différer du total historique du tableau de bord ; les incidents résolus peuvent inclure leur durée enregistrée.
- Le rapport capture les données à sa génération et n’envoie pas d’alertes de panne en direct.
Sections
aACMERapportPDF
Score de santé87/100
Position+24
Parlez de Surveillance de disponibilité. Avec SEO MCP.
Lisez via SEO MCP la disponibilité enregistrée sur 30 jours et les états/réponses récents. Vérifiez la date avant d’interpréter le dernier état comme actuel ; la réponse ne contient ni incidents ni codes HTTP.
- Screpy: Bonjour ! Regardons Surveillance de disponibilité pour example.com. Que souhaitez-vous savoir ?
- Vous: Explique la disponibilité enregistrée et le dernier contrôle d’example.com.
- Screpy: Résultat enregistré illustratif : contrôle à 10:18 UTC disponible, avec 99,95 % de contrôles réussis sur 30 jours. Ce taux repose sur des échantillons et ne prouve pas l’accès actuel. Consultez incidents du tableau de bord et journaux d’hébergement pour enquêter. Disponibilité enregistrée: Dernier contrôle: 10:18 UTC. Disponibilité sur 30 jours: 99,95 %.
- Vous: Transforme cela en un court plan d’action.
- Screpy: Je séparerai les constats des recommandations. Examinez les preuves, choisissez une modification puis vérifiez les résultats. Vos prochaines étapes: Examiner: Vérifier la source et la date de chaque constat.. Décider: Choisir la première modification.. Vérifier: Comparer les résultats après la modification..
- Vous: Peux-tu expliquer les preuves simplement ?
- Screpy: Oui. Interrogez-moi sur un résultat pris en charge pour comprendre ce qu’il montre, sa source et les incertitudes. Les données manquantes restent indisponibles ; les recommandations ne sont pas des corrections automatiques.
Mettez en place une boucle utile de surveillance de disponibilité.
Choisissez une cible publique, activez la surveillance et configurez une adresse responsable. Lors d’un échec, examinez les données actuelles et confirmez un contrôle réussi ultérieur.
-
Utilisez l'URL publique du projet
Utilisez l’URL publique prévue sans connexion obligatoire. Vérifiez les destinations séparément : les contrôles ne suivent pas les redirections.
-
Activez les contrôles et configurez l'intervalle
Activez la surveillance dans les paramètres, enregistrez intervalle et adresse facultative ; confirmez accès payant compatible et contrôles récents.
-
Examiner les derniers contrôles échoués
Consultez état, dernier contrôle, résultats HTTP et détails de l’incident. Examinez immédiatement une panne critique ; le taux sur 30 jours apporte du contexte, pas une raison d’attendre.
-
Enquêtez et confirmez le rétablissement
Comparez l’échec aux journaux de déploiement, DNS, TLS, hébergement et application. Confirmez un contrôle réussi ; résoudre l’incident ne valide pas tous les parcours.
Donnez la priorité aux sites où l'indisponibilité coûte réellement.
Utilisez des contrôles récurrents pour les projets dont la disponibilité affecte ventes, prospects, campagnes, accès client ou récupération du contenu public par les robots.
Sites de recherche organique
Surveillez le site public que robots et visiteurs organiques doivent atteindre avant que le contenu ou le référencement puisse compter.
Sites de lancement et de campagne
Suivez le site pendant lancements, migrations, refontes et campagnes actives lorsque le coût d'une indisponibilité est immédiat.
Portefeuilles multi-projets
Examinez l'uptime séparément pour chaque projet Screpy afin de gérer les sites clients ou de marque dans un seul flux.
Connaissez les limites d'un résultat d'uptime.
Screpy fournit des preuves HTTP externes et l'historique des incidents du site configuré. Utilisez infrastructure, journaux, tests transactionnels et données de recherche lorsque la question dépasse ce périmètre.
Une cible de site par projet
Uptime Monitoring vérifie l'URL publique configurée du projet Screpy ; ce n'est pas une liste générale de moniteurs de points de terminaison indépendants.
Contrôle externe, pas télémétrie d'infrastructure
Le résultat indique si la cible publique a répondu. Il n'inspecte ni CPU, mémoire, conteneurs, bases de données, réseaux privés ni journaux serveur.
Preuve d'incident, pas preuve de cause racine
Statut HTTP, délais et horodatages réduisent le champ d'enquête mais ne prouvent pas si DNS, TLS, hébergement, déploiement, pare-feu ou code était en cause.
Disponibilité ne signifie pas garantie SEO
Une page publique fonctionnelle est nécessaire aux visiteurs et au crawl, mais un uptime élevé ne garantit ni indexation, ni classements, ni trafic, ni revenus, ni conversions.
Utilisez le flux de santé du site adapté au problème.
Surveillez l'accessibilité dans le temps, auditez le site si les erreurs ou schémas de crawl se répètent, ou examinez les performances après stabilisation de la disponibilité.
Examinez disponibilité sur 30 jours fondée sur les contrôles, réponses, résultats HTTP et incidents de l’URL publique.
Explorez le site pour trouver les pages en échec récurrentes, les problèmes de redirection, les destinations cassées et les schémas techniques liés à l'incident.
Lancez des contrôles de performances en laboratoire lorsque le site est accessible mais que chargement ou réactivité nécessitent encore une enquête.
Documentation Screpy
Apprenez à surveiller la disponibilité d'un site
Apprenez à choisir une cible publique, configurer surveillance et notifications, interpréter les réponses et enquêter sur les incidents.
Questions sur la surveillance de disponibilité, réponses.
Réponses sur échantillonnage, projets inactifs, redirections, contrôles absents, e-mails admissibles et performance des pages.
Que mesure Screpy Uptime Monitoring ?
Screpy enregistre état, code HTTP disponible, réponse et date d’une URL publique. Le tableau de bord calcule disponibilité et moyennes sur 30 jours, affiche huit contrôles récents et, séparément, nombres historiques et cinq derniers incidents.
À quelle fréquence Screpy vérifie-t-il l'uptime ?
Les paramètres acceptent 1–60 minutes avec un accès payant. Dans la journée suivant l’activité de l’équipe, cet intervalle s’applique. Ensuite, au moins 10 minutes ; après sept jours, au moins 60. Après 30 jours inactifs, les contrôles planifiés cessent. Vérifiez la dernière date réelle.
Une panne peut-elle affecter le crawl ou l'indexation ?
Les erreurs serveur persistantes peuvent ralentir l’exploration et empêcher la récupération du contenu. Un résultat disponible ne prouve ni accès Googlebot, ni destination d’une redirection, ni indexation ou classement. Examinez aussi les données d’exploration et de recherche.
Comment fonctionnent les incidents de panne et le rétablissement ?
Le premier échec ouvre un incident, les suivants le maintiennent ouvert et un contrôle réussi le résout. Le tableau de bord montre état, début et détails ; les e-mails admissibles de rétablissement incluent la durée enregistrée. L’échantillonnage ne précise pas le début exact ni toutes les pannes brèves.
Screpy envoie-t-il des alertes de panne ?
Un échec ultérieur d’un incident ouvert peut déclencher un e-mail pour 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 ou 526. Membres et adresse supplémentaire distincte reçoivent les avis admissibles. Panne et rétablissement ont chacun une limite d’un e-mail par projet et par 24 heures. Un incident supprimé n’est pas renotifié plus tard ; le rétablissement nécessite une notification de panne antérieure non supprimée. Délais expirés, erreurs sans code et autres codes ne sont pas admissibles.
Que considère Screpy comme disponible ou indisponible ?
HTTP 200–399 est disponible ; les autres réponses indiquent une indisponibilité. Délai expiré et erreur sont distincts. Les redirections ne sont pas suivies et le contenu n’est pas validé : une redirection ou page d’erreur HTTP 200 peut être disponible sans confirmer la page attendue.
Uptime Monitoring affiche-t-il l'historique des temps de réponse ?
Oui. Jusqu’à 160 réponses récentes sur 30 jours alimentent le graphique, avec moins de points visibles sur petit écran. La tendance de cinq contrôles diffère de la moyenne des contrôles réussis sur 30 jours. La réponse HTTP ne mesure ni rendu ni interactions.
La surveillance de disponibilité remplace-t-elle celle du serveur ou des transactions ?
Non. Screpy contrôle une cible publique HTTP(S), sans inspecter l’infrastructure privée, exécuter connexion ou achat, valider le contenu, prouver une disponibilité géographique ou diagnostiquer la cause. Utilisez journaux et contrôles dédiés.
Le SEO voit grand. Votre budget respire.
Une boîte à outils SEO complète à un prix vraiment abordable.
- Audits techniques, suivi des positions et visibilité dans les IA
- Recherche de mots-clés, analyse des backlinks et suivi de disponibilité
- Un espace de travail. Des offres flexibles. Moins de dépenses.
Plus d’argent dans votre poche