Siti che generano ricavi
Tieni sotto controllo esterno ricorrente negozio, prenotazioni, prodotto in abbonamento o sito di acquisizione lead.
Monitoraggio uptime per siti SEO e orientati ai ricavi
Monitora l’URL pubblico del progetto, esamina disponibilità e risposte di 30 giorni e indaga sui controlli HTTP falliti. Affianca storico degli incidenti e email idonee al lavoro SEO.
Configura i controlli di disponibilità
Attiva controlli periodici sull’URL pubblico salvato nel progetto Screpy. Scegli una destinazione utile ai visitatori prima di impostare la frequenza.
- Ogni progetto monitora un URL HTTP o HTTPS, non un elenco separato di endpoint.
- Le impostazioni controllano attivazione, intervallo di 1–60 minuti e indirizzo di notifica facoltativo.
- I controlli pianificati richiedono un piano a pagamento attivo e idoneo; gli intervalli predefiniti variano.
- L’inattività del team allunga gli intervalli; dopo 30 giorni inattivi i controlli si fermano.
- Ultimo controllo indica la freschezza; l’intervallo impostato non garantisce un orario esatto di esecuzione.
example.com60 s
Comprendi la percentuale di uptime
Scopri quanti controlli hanno avuto successo negli ultimi 30 giorni. Leggi la percentuale insieme al numero di controlli e all’ultima data.
- L’uptime divide i controlli riusciti per tutti quelli registrati e moltiplica per 100.
- Lo stato attuale deriva dall’ultimo controllo completato nel periodo.
- Senza controlli registrati, i dati sono indisponibili, non pari al 100%.
- La percentuale si basa su campioni; non equivale direttamente a minuti di interruzione o a uno SLA ponderato per durata.
Disponibilità
93,8%503200
Segui i tempi di risposta
Individua risposte lente e fallimenti ripetuti nel grafico. Un URL raggiungibile può comunque rispondere lentamente.
- Il grafico usa fino a 160 controlli recenti di 30 giorni; la larghezza dello schermo determina la parte visibile.
- La tendenza calcola la media di cinque controlli; la risposta media usa quelli riusciti dell’intero periodo di 30 giorni.
- I tempi misurano la latenza HTTP, non il caricamento completo, i Core Web Vitals o un percorso del visitatore.
Tempo di risposta
240 msEsamina gli stati HTTP
Consulta gli otto ultimi controlli con stato, data, codice HTTP e risposta. Confrontali con il comportamento previsto dell’URL pubblico.
- HTTP 200–399 indica disponibilità; le altre risposte HTTP indisponibilità. Timeout ed errore restano separati.
- I reindirizzamenti non vengono seguiti: un risultato 3xx non conferma la destinazione.
- Si usa HEAD, riprovando con GET su 405 o 501; un errore di connessione può non avere codice HTTP.
- Uno stato disponibile non verifica contenuti, moduli o acquisti; anche una pagina di errore HTTP 200 può risultare disponibile.
Stato HTTP
200GET /HTTP/2 200Esamina gli incidenti di downtime
Segui un incidente dal primo controllo fallito a uno successivo riuscito. L’indagine sulla causa resta separata.
- Il primo fallimento apre l’incidente, i successivi lo aggiornano, il primo successo lo risolve.
- La dashboard mostra conteggi storici di incidenti aperti e risolti e gli ultimi cinque con stato, inizio e dettagli.
- Gli orari riflettono i controlli, non l’inizio esatto tra campioni; brevi interruzioni possono sfuggire.
Periodo
12 min503200
Ricevi email di interruzione
Invia avvisi idonei ai membri del progetto e a un indirizzo aggiuntivo facoltativo. L’incidente viene registrato prima di poter generare un’email.
- Un fallimento successivo dello stesso incidente può inviare email per codici supportati come 404, 500 o 503.
- Timeout, errori di connessione e codici non supportati sono registrati senza generare queste email.
- Ogni progetto ha limiti separati di un’email di interruzione e una di ripristino ogni 24 ore.
- Il ripristino richiede un incidente già notificato e non soppresso; la durata registrata non prova l’esatta interruzione vissuta dai visitatori.
!
Progettoexample.com
RevisioneLeggi i dati uptime con SEO MCP
Chiedi a un assistente connesso di spiegare risultati salvati di un progetto accessibile. Usa la data per distinguere dati registrati da un nuovo controllo.
- SEO MCP restituisce stato di 30 giorni, percentuale, media dei controlli riusciti e ultimo controllo.
- Fino a 160 record recenti includono stato, risposta e data, senza codici HTTP o incidenti.
- La lettura non avvia controlli né identifica o risolve interruzioni; i risultati mancanti restano indisponibili.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Aggiungi uptime ai report SEO
Condividi dati di disponibilità in un report salvato per cliente o team. Un’istantanea risponde a una domanda diversa dal monitoraggio in diretta.
- Il widget include statistiche di 30 giorni, controlli recenti e incidenti sovrapposti al periodo del report.
- Il conteggio può differire da quello storico della dashboard; gli incidenti risolti possono includere la durata registrata.
- Il report acquisisce dati salvati alla generazione e non invia avvisi in diretta.
Sezioni
aACMEReportPDF
Punteggio di salute87/100
Posizione+24
Parla di Monitoraggio uptime. Con SEO MCP.
Leggi con SEO MCP uptime salvato di 30 giorni e record recenti di stato e risposta. Verifica la data prima di considerarli disponibilità attuale; non include incidenti o codici HTTP.
- Screpy: Ciao! Vediamo Monitoraggio uptime per example.com. Cosa vuoi sapere?
- Tu: Spiega l’uptime salvato e la data dell’ultimo controllo di example.com.
- Screpy: Esempio di risultato salvato: il controllo delle 10:18 UTC era disponibile, con il 99,95% di controlli riusciti su 30 giorni. La percentuale è campionaria e non prova l’accesso attuale. Indaga con incidenti della dashboard e log di hosting. Riepilogo salvato: Ultimo controllo: 10:18 UTC. Uptime di 30 giorni: 99,95%.
- Tu: Trasformalo in un breve piano d’azione.
- Screpy: Terrò separati i risultati dalle raccomandazioni. Esamina le prove, scegli una modifica e controlla poi i risultati. I prossimi passi: Esamina: Controlla fonte e data di ogni risultato.. Decidi: Scegli la prima modifica.. Verifica: Confronta i risultati dopo la modifica..
- Tu: Puoi spiegare le prove con parole semplici?
- Screpy: Sì. Chiedi di un risultato supportato e spiegherò cosa mostra, da dove proviene e quali incertezze restano. I dati mancanti restano indisponibili; le raccomandazioni non sono correzioni automatiche.
Crea un ciclo utile di monitoraggio uptime.
Scegli una destinazione pubblica, attiva il monitoraggio e configura un indirizzo responsabile. In caso di errore, esamina i record attuali e conferma un controllo successivo riuscito.
-
Usa l'URL pubblico del progetto
Usa l’URL pubblico previsto senza accesso obbligatorio. Verifica separatamente le destinazioni, perché i controlli non seguono reindirizzamenti.
-
Attiva i controlli e configura l'intervallo
Attiva il monitoraggio nelle impostazioni, salva intervallo e indirizzo facoltativo; conferma accesso a pagamento idoneo e controlli recenti.
-
Indaga sugli ultimi controlli falliti
Leggi stato, ultimo controllo, esiti HTTP e dettagli. Un errore critico va indagato subito; la percentuale di 30 giorni offre contesto, non un motivo per aspettare.
-
Analizza e conferma il ripristino
Confronta l’errore con log di distribuzione, DNS, TLS, hosting e applicazione. Conferma un controllo riuscito; risolvere l’incidente non verifica ogni percorso dei visitatori.
Dai priorità ai siti dove il downtime ha un costo reale.
Usa controlli ricorrenti per progetti in cui la disponibilità influenza vendite, lead, campagne, accesso dei clienti o recupero dei contenuti pubblici da parte dei crawler.
Proprietà della ricerca organica
Osserva il sito pubblico che crawler e visitatori organici devono raggiungere prima che contenuti o ranking possano contare.
Siti di lancio e campagne
Monitora il sito durante lanci, migrazioni, redesign e campagne attive, quando un problema di disponibilità ha un costo immediato.
Portafogli con più progetti
Esamina l'uptime separatamente per ogni progetto Screpy e gestisci siti cliente o brand nello stesso flusso.
Conosci i limiti di un risultato uptime.
Screpy offre prove HTTP esterne e storico degli incidenti per il sito configurato. Usa infrastruttura, log, test transazionali e dati di ricerca quando la domanda supera questo perimetro.
Un sito per progetto
Uptime Monitoring controlla l'URL pubblico configurato per il progetto Screpy; non è un elenco generico di monitor indipendenti.
Controllo esterno, non telemetria dell'infrastruttura
Il risultato descrive se la destinazione pubblica ha risposto. Non ispeziona CPU, memoria, container, database, reti private o log del server.
Prova dell'incidente, non della causa
Stato HTTP, tempi e orari restringono l'analisi ma non dimostrano se la causa fosse DNS, TLS, hosting, deploy, firewall o codice.
Disponibilità non è una garanzia SEO
Una pagina pubblica funzionante è necessaria a visitatori e crawler, ma un uptime elevato non garantisce indicizzazione, ranking, traffico, ricavi o conversioni.
Usa il flusso di salute del sito adatto al problema.
Monitora la raggiungibilità nel tempo, analizza l'intero sito quando errori o pattern di crawling si ripetono, oppure controlla le prestazioni dopo aver stabilizzato la disponibilità.
Esamina uptime di 30 giorni basato sui controlli, risposte, esiti HTTP e incidenti dell’URL pubblico.
Scansiona il sito per trovare pagine fallite ricorrenti, problemi di redirect, destinazioni non funzionanti e pattern tecnici attorno a un problema di disponibilità.
Esegui controlli di prestazioni in laboratorio quando il sito è raggiungibile ma caricamento o reattività richiedono ancora analisi.
Documentazione di Screpy
Impara a monitorare l'uptime del sito
Impara a scegliere una destinazione pubblica, configurare monitoraggio e notifiche, interpretare risposte e indagare sugli incidenti.
Domande sul monitoraggio uptime, con risposta.
Risposte su campionamento, progetti inattivi, reindirizzamenti, controlli mancanti, email idonee e prestazioni delle pagine.
Screpy invia avvisi di downtime?
Un errore successivo in un incidente aperto può generare email su 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 o 526. Membri e indirizzo aggiuntivo distinto ricevono gli avvisi idonei. Interruzione e ripristino hanno ciascuno un limite di un’email per progetto ogni 24 ore. Un incidente soppresso non viene notificato più tardi; il ripristino richiede una notifica precedente non soppressa. Timeout, errori senza codice e altri codici non sono idonei.
Che cosa misura Screpy Uptime Monitoring?
Screpy registra stato, codice HTTP disponibile, risposta e data di un URL pubblico. La dashboard calcola percentuale e medie sui controlli di 30 giorni, mostra otto controlli recenti e separatamente conteggi storici e ultimi cinque incidenti.
Un downtime può influire su crawling o indicizzazione?
Errori server persistenti possono rallentare la scansione e impedire il recupero dei contenuti. Un risultato disponibile non prova accesso Googlebot, destinazione dei redirect, indicizzazione o ranking. Indaga anche con dati di scansione e ricerca.
Uptime Monitoring mostra lo storico dei tempi di risposta?
Sì. Il grafico carica fino a 160 risposte recenti di 30 giorni, meno visibili sugli schermi piccoli. La tendenza di cinque controlli differisce dalla media dei controlli riusciti dei 30 giorni. La risposta HTTP non misura rendering o interazioni.
Come funzionano incidenti e ripristino?
Il primo errore apre l’incidente, i successivi lo mantengono aperto e un controllo riuscito lo risolve. La dashboard mostra stato, inizio e dettagli; le email idonee di ripristino includono la durata registrata. I campioni non individuano l’inizio esatto né ogni breve interruzione.
Con quale frequenza Screpy controlla l'uptime?
Le impostazioni accettano 1–60 minuti con accesso a pagamento. Entro un giorno dall’attività del team si usa quell’intervallo; dopo almeno 10 minuti e dopo sette giorni almeno 60. Dopo 30 giorni inattivi cessano i controlli pianificati. Consulta sempre l’ultima data effettiva.
Che cosa considera Screpy disponibile o non disponibile?
HTTP 200–399 indica disponibilità, altre risposte HTTP indisponibilità; timeout ed errori sono stati distinti. Non si seguono reindirizzamenti né si verifica il contenuto: un redirect o una pagina di errore HTTP 200 può risultare disponibile senza confermare la pagina prevista.
Il monitoraggio uptime sostituisce quello del server o delle transazioni?
No. Screpy controlla una destinazione HTTP(S) pubblica. Non esamina infrastruttura privata, esegue accessi o acquisti, verifica contenuti, prova disponibilità geografica o diagnostica cause. Usa log e controlli specifici.
Grande nella SEO. Leggero sul portafoglio.
Una suite completa di strumenti SEO a un prezzo davvero accessibile.
- Audit tecnici, monitoraggio delle posizioni e visibilità nelle IA
- Ricerca di parole chiave, backlink e monitoraggio della disponibilità
- Un solo spazio di lavoro. Piani flessibili. Meno spese.
Più soldi in tasca