Sites de receita
Mantenha loja, site de reservas, produto por assinatura ou site de geração de leads sob verificações externas recorrentes.
Monitoramento de uptime para sites de SEO e receita
Monitore a URL pública do projeto, revise disponibilidade e respostas de 30 dias e investigue verificações HTTP com falha. Mantenha histórico de incidentes e emails elegíveis junto ao trabalho SEO.
Configure verificações de disponibilidade
Ative verificações recorrentes da URL pública salva no projeto Screpy. Escolha um destino útil para visitantes antes de definir a frequência.
- Cada projeto monitora uma URL HTTP ou HTTPS, não uma lista separada de endpoints.
- As configurações controlam ativação, intervalo de 1–60 minutos e email opcional de notificação.
- Verificações programadas exigem plano pago ativo e elegível; os intervalos padrão variam.
- A inatividade da equipe aumenta os intervalos; após 30 dias inativos, as verificações param.
- Última verificação indica a atualização; o intervalo configurado não garante horário exato de execução.
example.com60 s
Entenda a porcentagem de uptime
Veja a proporção de verificações bem-sucedidas nos últimos 30 dias. Leia a porcentagem junto com a quantidade e a última data.
- O uptime divide verificações bem-sucedidas por todas as registradas e multiplica por 100.
- O status atual vem da última verificação concluída nesse período.
- Sem verificações registradas, os dados ficam indisponíveis, não em 100%.
- A porcentagem usa amostras; não pode ser convertida diretamente em minutos de indisponibilidade ou SLA ponderado por tempo.
Disponibilidade
93,8%503200
Acompanhe tempos de resposta
Identifique respostas lentas e falhas repetidas no gráfico. Uma URL acessível também pode responder lentamente.
- O gráfico usa até 160 verificações recentes de 30 dias; a largura da tela determina a parte visível.
- A tendência calcula a média de cinco verificações; a resposta média usa as bem-sucedidas dos 30 dias completos.
- Os tempos medem latência HTTP, não carregamento completo, Core Web Vitals ou uma jornada do visitante.
Tempo de resposta
240 msRevise os status HTTP
Veja as oito últimas verificações com status, data, código HTTP e resposta. Compare com o comportamento esperado da URL pública.
- HTTP 200–399 conta como disponível; outras respostas HTTP, como indisponível. Tempo esgotado e erro são registrados separadamente.
- Redirecionamentos não são seguidos: um resultado 3xx não confirma o destino.
- As verificações usam HEAD, tentando GET em 405 ou 501; falhas de conexão podem não ter código HTTP.
- Um resultado disponível não valida conteúdo, formulários ou compras; uma página de erro HTTP 200 também pode contar como disponível.
Estado HTTP
200GET /HTTP/2 200Revise incidentes de indisponibilidade
Acompanhe o incidente da primeira falha até uma verificação posterior bem-sucedida. Investigue a causa separadamente.
- A primeira falha abre um incidente; as seguintes o atualizam e o primeiro sucesso o resolve.
- O painel mostra totais históricos de incidentes abertos e resolvidos e os cinco últimos com status, início e detalhes.
- Os horários refletem verificações, não o início exato entre amostras; quedas breves podem passar despercebidas.
Período
12 min503200
Receba emails de indisponibilidade
Envie avisos elegíveis aos membros e a um endereço adicional opcional. O registro do incidente começa antes de se tornar elegível para email.
- Uma falha posterior do mesmo incidente pode gerar email com códigos aceitos como 404, 500 ou 503.
- Tempos esgotados, erros de conexão e códigos não aceitos são registrados, mas não geram esses emails.
- Cada projeto tem limites separados de um email de queda e um de recuperação por 24 horas.
- A recuperação exige incidente já notificado e não suprimido; a duração registrada não prova a queda exata vivida pelos visitantes.
!
Projetoexample.com
RevisãoLeia uptime pelo SEO MCP
Peça a um assistente conectado que explique resultados salvos de um projeto acessível. Use a data para distinguir registros de uma nova verificação.
- O SEO MCP retorna status de 30 dias, porcentagem, média das verificações bem-sucedidas e última verificação.
- Até 160 registros recentes incluem status, resposta e data; o resumo não contém códigos HTTP ou incidentes.
- A leitura não executa novas verificações nem identifica ou corrige quedas; resultados ausentes continuam indisponíveis.
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}Adicione uptime a relatórios SEO
Compartilhe dados de disponibilidade em um relatório salvo para cliente ou equipe. Um retrato do período difere do monitoramento ao vivo.
- O widget inclui estatísticas de 30 dias, verificações recentes e incidentes que se sobrepõem ao período do relatório.
- O total pode diferir do histórico do painel; incidentes resolvidos podem incluir sua duração registrada.
- O relatório captura dados salvos na geração e não envia alertas ao vivo.
Seções
aACMERelatórioPDF
Pontuação de saúde87/100
Posição+24
Converse sobre Monitoramento de uptime. Com SEO MCP.
Leia pelo SEO MCP o uptime salvo de 30 dias e registros recentes de status e resposta. Confira a data antes de considerar o último status atual; não inclui incidentes ou códigos HTTP.
- Screpy: Olá! Vamos analisar Monitoramento de uptime para example.com. O que você quer saber?
- Você: Explique o uptime salvo e a última verificação de example.com.
- Screpy: Resultado salvo ilustrativo: a verificação de 10:18 UTC marcou disponível, com 99,95% de sucessos em 30 dias. A porcentagem é amostral e não prova acesso agora. Investigue com incidentes do painel e registros de hospedagem. Resumo salvo: Última verificação: 10:18 UTC. Uptime de 30 dias: 99,95%.
- Você: Transforme isso em um breve plano de ação.
- Screpy: Vou separar os resultados das recomendações. Revise as evidências, escolha uma mudança e confira os resultados depois. Seus próximos passos: Revise: Confira a fonte e a data de cada resultado.. Decida: Escolha a primeira mudança.. Verifique: Compare os resultados após a mudança..
- Você: Você pode explicar as evidências em linguagem simples?
- Screpy: Sim. Pergunte sobre um resultado compatível e explicarei o que mostra, de onde vem e o que continua incerto. Dados ausentes continuam indisponíveis; recomendações não são correções automáticas.
Configure um ciclo útil de monitoramento de uptime.
Escolha um destino público, ative o monitoramento e configure um email responsável. Diante de falhas, investigue os registros atuais e confirme uma verificação posterior bem-sucedida.
-
Use a URL pública do projeto
Use a URL pública prevista, sem login obrigatório. Verifique destinos separadamente: essas verificações não seguem redirecionamentos.
-
Ative verificações e configure o intervalo
Ative o monitoramento nas configurações, salve intervalo e email opcional; confirme acesso pago elegível e verificações recentes.
-
Investigue as últimas verificações com falha
Leia status, última verificação, resultados HTTP e detalhes. Investigue falhas críticas agora; a porcentagem de 30 dias dá contexto, não motivo para esperar.
-
Investigue e confirme a recuperação
Compare a falha com registros de publicação, DNS, TLS, hospedagem e aplicação. Confirme uma verificação bem-sucedida; resolver o incidente não valida todas as jornadas.
Priorize sites onde o downtime tem custo real.
Use verificações recorrentes para projetos cuja disponibilidade afeta vendas, leads, campanhas, acesso dos clientes ou a recuperação de conteúdo público pelos crawlers.
Propriedades de busca orgânica
Acompanhe o site público que crawlers e visitantes orgânicos precisam alcançar antes que conteúdo ou ranking possam fazer diferença.
Sites de lançamento e campanhas
Monitore o site durante lançamentos, migrações, redesigns e campanhas ativas, quando um problema de disponibilidade tem custo imediato.
Portfólios com vários projetos
Analise o uptime separadamente para cada projeto Screpy e mantenha sites de clientes ou marcas no mesmo fluxo.
Conheça os limites de um resultado de uptime.
O Screpy fornece evidências HTTP externas e histórico de incidentes para o site configurado. Use infraestrutura, logs, testes de transação e dados de busca quando a pergunta ultrapassar esse escopo.
Um site por projeto
O Uptime Monitoring verifica a URL pública configurada para o projeto Screpy; não é uma lista geral de monitores de endpoints independentes.
Verificação externa, não telemetria de infraestrutura
O resultado descreve se o destino público respondeu. Não inspeciona CPU, memória, containers, bancos de dados, redes privadas ou logs do servidor.
Evidência de incidente, não prova da causa raiz
Status HTTP, tempos e horários restringem a investigação, mas não comprovam se DNS, TLS, hospedagem, deploy, firewall ou código causou o problema.
Disponibilidade não é garantia de SEO
Uma página pública funcionando é necessária para visitantes e crawling, mas uptime alto não garante indexação, rankings, tráfego, receita ou conversões.
Use o fluxo de saúde do site adequado à falha.
Monitore a acessibilidade ao longo do tempo, audite o site quando falhas ou padrões de crawling se repetirem ou analise o desempenho depois que a disponibilidade estiver estável.
Revise uptime de 30 dias baseado em verificações, respostas, resultados HTTP e incidentes da URL pública.
Rastreie o site para encontrar páginas com falha, problemas de redirecionamento, destinos quebrados e padrões técnicos ligados à indisponibilidade.
Execute verificações de desempenho em laboratório quando o site estiver acessível, mas carregamento ou responsividade ainda precisarem de investigação.
Documentação do Screpy
Aprenda a monitorar o uptime do site
Aprenda a escolher um destino público, configurar monitoramento e avisos, interpretar respostas e investigar incidentes.
Perguntas sobre monitoramento de uptime, respondidas.
Respostas sobre amostras, projetos inativos, redirecionamentos, verificações ausentes, emails elegíveis e desempenho das páginas.
O que o Screpy Uptime Monitoring mede?
O Screpy registra status, código HTTP quando disponível, resposta e data de uma URL pública. O painel usa verificações de 30 dias para porcentagem e médias, mostra oito verificações recentes e, separadamente, totais históricos e cinco últimos incidentes.
Com que frequência o Screpy verifica o uptime?
As configurações aceitam 1–60 minutos com acesso pago. Dentro de um dia da atividade da equipe, usa-se esse intervalo. Depois, no mínimo 10 minutos; após sete dias, no mínimo 60. Após 30 dias inativos, as verificações programadas param. Consulte sempre a última data real.
Uma queda do site pode afetar crawling ou indexação?
Erros persistentes do servidor podem reduzir o rastreamento e impedir a obtenção do conteúdo. Um resultado disponível não comprova acesso do Googlebot, destino de redirect, indexação ou posições. Investigue também com dados de rastreamento e pesquisa.
Como funcionam incidentes de indisponibilidade e recuperação?
A primeira falha abre um incidente, as seguintes o mantêm aberto e uma verificação bem-sucedida o resolve. O painel mostra status, início e detalhes; emails elegíveis de recuperação incluem duração registrada. Amostras não determinam início exato nem detectam toda queda breve.
O Screpy envia alertas de indisponibilidade?
Uma falha posterior em incidente aberto pode gerar email para 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 ou 526. Membros e email adicional distinto recebem avisos elegíveis. Queda e recuperação têm limites separados de um email por projeto a cada 24 horas. Um incidente suprimido não é notificado depois; recuperação exige aviso anterior de queda não suprimido. Tempos esgotados, erros sem código e outros códigos não são elegíveis.
O que o Screpy considera disponível ou indisponível?
HTTP 200–399 é disponível; outras respostas HTTP são indisponíveis. Tempo esgotado e erro são estados separados. Redirecionamentos não são seguidos e o conteúdo não é validado: um redirect ou página de erro HTTP 200 pode contar como disponível sem confirmar a página esperada.
O Uptime Monitoring mostra histórico de tempo de resposta?
Sim. O gráfico carrega até 160 respostas recentes de 30 dias, com menos pontos visíveis em telas menores. A tendência de cinco verificações difere da média dos sucessos de 30 dias. A resposta HTTP não mede renderização ou interações.
O monitoramento de uptime substitui o monitoramento de servidor ou transações?
Não. O Screpy verifica um destino HTTP(S) público. Não inspeciona infraestrutura privada, executa login ou compras, valida conteúdo, comprova disponibilidade geográfica nem diagnostica causas. Use registros e verificações específicas.
Forte em SEO. Leve no seu bolso.
Um conjunto completo de ferramentas de SEO a um preço realmente acessível.
- Auditorias técnicas, acompanhamento de posições e visibilidade em IA
- Pesquisa de palavras-chave, backlinks e monitoramento de disponibilidade
- Um espaço de trabalho. Planos flexíveis. Menos gastos.
Mais dinheiro no seu bolso