La validazione delle pagine è un sistema che sintetizza ogni documento in una serie di elementi con una gerarchia; ogni elemento può essere collocato al di sotto di altri (livello inferiore) o di seguito (pari livello) e all'occorrenza può avere determinati attributi, specifici per ogni elemento. Questa gerarchia è nota con il nome di DOM (Document Object Model). Il DOM altro non è che un'interfaccia di programmazione dell'applicazione (API) per documenti HTML e XML alla quale è possibile accedere da diversi linguaggi di programmazione e con la quale si può accedere al singolo nodo del documento.
Esiste poi un secondo tipo di validazione, quello WAI, molto più rigorosa (e che richiede più tempo per l'ottimizzazione).
Per validare una pagina esistono molti strumenti, sia on line che off-line. Tra quest'ultimi il più famoso è sicuramente il CSE HTML Validator di Albert Weirsch, mentre tra quelli on line, manco a dirlo ovviamente il più famoso e il più attendibile è quello del consorzio W3C.
Per validare una pagina, ogni software segue la propria logica, ma fondamentalmente si può riassumere il tutto aprire un URL / file e farlo "leggere" dal motore di analisi che dopo aver parsato il documento, restituirà un report contenente errori e segnalazioni varie che dovranno essere corrette al fine di ritornare una pagina valida.
Esistono poi altri sistemi di validazione; per esempio direttamente nel browser (in particolare per Firefox) dove con l'installazione di un plug-in si può validare il documento visualizzato senza mai abbandonare il browser. Di plug-in per Firefox ne esistono diversi.
Ad oggi i motori di ricerca sono poco inclini all'analisi degli errori HTML, quindi alla loro validazione, e si limitano a leggere prevalentemente i contenuti al di fuori dei tag (e in alcuni casi il testo contenuto nel codice javascript in line).
Per chi si sta chiedendo se i MDR abbiano un sistema di controllo della validità del codice, la risposta trova diverse argomentazione. C'è chi dice che i principali e più potenti effettuano un controllo della struttura HTML basato sull'analisi del DOM (document object model) di ogni singola pagina (non sul WAI, più esigente e rigoroso), chi invece sostiene che non venga effettuato alcun controllo (e questo potrebbe giustificare il fatto che molti risultati presenti nelle SERP riconducano a pagine di bassissimo profilo tecnico e contenutistico).
Premessa a parte, gli errori HTML in relazione ai MDR si possono classificare in due macro categorie.
La prima è quella degli errori "semplici" che, seppure generando un output differente dalle intenzioni dell'impaginatore, non comportano una mancata visualizzazione del testo.
Per esempio:
Codice:
<TABLE BORDER=1 WIDTH=200> <TR><TD>Table content</TR> </TABLE>
la mancata chiusura del tag TableData non causa l'omissione del testo "Table content" nella tabella all'interno del documento.
Per esser più precisi le specifiche del W3C stabiliscono che la chiusura di entrambi i tag TD e TR non è obbligatoria (se non ci credete, guardate qui a metà pagina) pertanto un browser W3C conformante chiude normalmente la tabella senza farsi problemi. Sia MSIE sia FF rispettano questa specifica, e, ciò che più ci interessa, anche gli spider leggono quel contenuto per indicizzarlo.
Nell'esempio visto sopra non c'è conseguenza visibile all'errore dell'impaginatore.
Vediamo invece questo esempio:
Codice:
<FONT FACE="Arial SIZE="4">text</FONT>
In questo caso il testo inserito all'interno dei tag non sarà né Arial né di dimensione 4. Questo è un errore più visibile perché a livello grafico si ottiene qualcosa di diverso da quanto desiderato. Il testo stampato a video non sarà formattato come si vorrebbe. Anche in questo caso però gli spider non si fanno problemi: indicizzano il contenuto di quei tag.
La seconda categoria è quella degli "errori gravi": quegli errori di marcatura che fanno sì che non sia stampato a video il contenuto desiderato. Fa parte di questa categoria di errori l'omissione di virgolette singole ' e doppie " o degli apici < e >.
Per esempio:
Codice:
<FONT FACE="Arial SIZE=4>contenuto del tag "font"</FONT>
In questo caso l'analisi DOM non è in grado di stabilire dove finisca il tag di apertura, dal momento che l'apice ">" che ne delimita la chiusura si trova per errore all'interno del valore dell'attributo FACE. Di conseguenza è come se non esistesse. Infatti viene letto: Codice:
<FONT FACE="unknown font"</FONT>
e avrà valore solo il tag di chiusura , con conseguente risultato di chiusura di altri eventuali tag FONT aperti in precedenza. Di fatto il contenuto dei tag è nullo e non viene letto dal browser (provare per credere) né dallo spider.
Alla domanda "Si può essere penalizzati a causa della struttura DOM non formalmente corretta?". La risposta, almeno al momento, è no.
Se così fosse troppi siti ne sarebbero penalizzati. Tuttavia se Google, così come gli altri motori, volessero aumentare la qualità dei risultati delle loro SERP, non dovrebbe far altro che muovere un dito svalutando quei risultati che secondo il DOM risultino imperfetti.
Il seguente documento è stato redatto sulla base del post di emanueledg e rielaborato da Moroandrea