Codice di stato HTTP 200

Cosa verifica questo controllo

Invia una richiesta GET all’URL sottoposto ad audit e legge il codice di stato HTTP finale. Il controllo passa solo su 200 OK. Segnala:

• redirect 3xx (l’URL non è quello canonico)
• errori 4xx (404 pagina non trovata, 410 gone, 403 forbidden)
• errori 5xx (crash del server, gateway timeout)

Il crawler segue fino a un piccolo numero di redirect così può dirti anche lo stato finale alla fine della catena.

Perché è importante

I motori di ricerca e i crawler IA trattano le risposte non-200 come “non indicizzare questo URL”.

• 301/302 — l’URL non avrà posizionamento; ce l’avrà il target del redirect. Se hai condiviso example.com/old-post e fa 301 verso example.com/new-post, ogni backlink, ogni condivisione social, ogni selezione di featured snippet punta a un URL che Google rimuoverà dal suo indice entro settimane.
• 404 / 410 — l’URL viene rimosso dall’indice. Se è successo per sbaglio (refuso in una regola di redirect, slash finale mancante, pagina cancellata che ha ancora backlink), stai perdendo traffico in silenzio.
• 500 / 502 / 503 / 504 — Google riprova, poi de-indicizza dopo qualche giorno di fallimenti. Peggio, Googlebot ridurrà il crawl budget per l’intero dominio.

Una pagina che restituisce qualsiasi cosa diversa da 200 è invisibile.

Come sistemarlo

Per prima cosa, vedi esattamente cosa restituisce il server. curl -I mostra la catena completa:

curl -ILso /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/page

Aggiungi -L e -w "%{http_code} -> %{redirect_url}\n" per mappare ogni hop. Se vedi più righe 30x prima del 200 finale, hai una catena di redirect — anche quella vale la pena sistemarla.

Se l’URL dovrebbe restituire 200 ma restituisce 301/302:

Alcuni colpevoli comuni:

• Mismatch www o trailing-slash — example.com/page fa 301 a example.com/page/. Scegli una forma canonica (con o senza slash) e linka coerentemente. Non linkare la forma redirezionata internamente.
• Upgrade HTTPS — http://example.com/page fa 301 a https://example.com/page. Atteso, ma assicurati che tutti i link interni e la sitemap usino HTTPS così i crawler non incappano mai nel redirect. Vedi Redirect HTTP a HTTPS.
• Redirect localizzato sul path root — / fa 302 a /en/ in base ad Accept-Language. Googlebot crawla dagli USA con en-US, quindi / diventa un redirect a /en/. O fai sì che / serva direttamente il contenuto inglese (con hreflang per le altre localizzazioni) o usa un 302 più x-default hreflang.

Se l’URL restituisce 404 per sbaglio:

• Controlla la config di routing (nginx try_files, Next.js [...slug].tsx, Astro getStaticPaths).
• Controlla la sensibilità alle maiuscole — /About e /about sono URL diversi sui server Linux.
• Controlla il database — una pagina CMS in stato “draft” restituisce 404 nella maggior parte dei template.

Se la pagina è davvero scomparsa, restituisci 410 Gone invece di 404 — Google de-indicizza i 410 circa due volte più velocemente. Imposta una pagina 404 personalizzata così la risposta resta utile per gli umani.

Se l’URL restituisce 5xx:

Questo è un problema di server, non di configurazione. Controlla i log dell’applicazione al timestamp in cui MetricSpot ha eseguito l’audit. Cause comuni: pool di connessioni al database esaurito, out-of-memory su una funzione serverless, API di terze parti da cui dipende la pagina che ha restituito un timeout.

Ricette:

# nginx — 200 esplicito per una route, no redirect
location = /pricing {
  try_files /pricing.html =404;
}

// Express — restituisce 410 per URL rimossi permanentemente
app.get("/old-product/:id", (req, res) => res.status(410).send("Gone"));

// Next.js (App Router) — restituisce 410 da un segmento route
import { notFound } from "next/navigation";
export default async function Page({ params }) {
  const product = await getProduct(params.id);
  if (!product) notFound(); // restituisce 404 di default
  // ...
}

Per i siti statici Astro, un 410 va servito dal tuo host (nginx return 410; o Cloudflare Worker), poiché l’output statico di Astro emette solo 404 per le route mancanti.

Domande frequenti

Il 301 è sempre cattivo?

No. Un 301 è corretto quando l’URL si è effettivamente spostato — vecchio slug a nuovo slug, HTTP a HTTPS, www a non-www. È cattivo solo quando MetricSpot fa l’audit dell’URL che intendi essere canonico e fa 301 altrove — significa che hai dato a noi (e a Google, e a ogni backlink) l’URL sbagliato.

Dovrei restituire 200 per pagine mancanti con un messaggio “non trovata”?

No. Restituire 200 con contenuto “pagina non trovata” si chiama soft 404. Google lo rileva (per pattern di contenuto) e lo tratta comunque come 404, ma confonde gli analytics e gonfia il tuo crawl budget. Restituisci sempre lo stato HTTP corretto.

E il 304 Not Modified?

304 è una risposta condizionale di successo — il browser ha già la pagina in cache. Non è un problema; MetricSpot non invia header If-Modified-Since quindi normalmente non lo vedrai nel nostro crawl. Se lo vedi, la tua CDN è troppo aggressiva nel cachare risposte a GET non autenticate.