La etiqueta Meta Charset
Qué hace <meta charset="utf-8">, por qué la especificación HTML la quiere en los primeros 1024 bytes, cómo una codificación incorrecta causa mojibake, y por qué es un problema de corrección de renderizado más que un factor de ranking.
Idiomas
1 señal de evidencia en esta página
- Herramienta activa relacionadaHTTP Header Checker
La etiqueta meta charset — <meta charset="utf-8"> — declara la codificación de caracteres de tu página para que los navegadores y rastreadores conviertan los bytes crudos en los caracteres correctos. La especificación HTML la requiere dentro de los primeros 1024 bytes del documento, y la mejor práctica es que sea el primer hijo literal de <head>. Si la pones mal (falta, tarde, o con una codificación no coincidente) obtienes mojibake: letras acentuadas, comillas curvas, guiones largos, escrituras no latinas y emojis se renderizan como basura — lo que puede corromper lo que se muestra y se indexa. NO es un factor de ranking directo; la única guía de Google es 'usar Unicode/UTF-8 cuando sea posible'. UTF-8 es la codificación casi universal y requerida por la especificación para HTML5 hoy. Una cabecera Content-Type enviada por el servidor con charset anula la etiqueta en la página, lo cual es una fuente común de errores de migración. Esta es una de las etiquetas orientadas al navegador en el clúster de meta etiquetas.
TL;DR — La etiqueta meta charset es una línea de HTML —
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encoding<meta charset="utf-8">— que le dice al navegador cómo leer el texto de tu página. Si la pones mal o la omites, los caracteres especiales (acentos, comillas curvas, emojis) pueden convertirse en galimatías. No te ayuda a posicionarte, pero el texto con aspecto roto es malo para todos, incluido Google. Ponla primero en tu<head>y usautf-8. Listo.
Qué hace la etiqueta
Cada página web se almacena como bytes sin procesar. Esos bytes solo se convierten en las letras que lees una vez que algo decide qué carácter representa cada byte (o grupo de bytes). La etiqueta meta charset es cómo tu página le dice al navegador — y a los rastreadores de los motores de búsqueda — qué sistema usar:
<meta charset="utf-8">utf-8 es la codificación que quieres en casi todos los casos. Puede representar prácticamente
todos los caracteres y escrituras en uso hoy en día, además de emojis, todo en un solo sistema.
Qué sale mal sin ella
Si no declaras una codificación, el navegador tiene que adivinar. Cuando adivina mal,
obtienes mojibake — texto ilegible donde un apóstrofo curvo se convierte en algo como
’, o café aparece como café. Las letras acentuadas, las rayas, las comillas
“inteligentes”, las escrituras no latinas (árabe, cirílico, chino, japonés) y los emojis son las
víctimas habituales. El inglés sencillo sin acentos puede verse bien incluso cuando la codificación es incorrecta,
que es exactamente por lo que el error pasa desapercibido.
Dónde ponerla
Dos reglas sencillas:
- Pon
<meta charset="utf-8">primero dentro de tu<head>, antes del título o de cualquier otra cosa. - Usa
utf-8, no alguna codificación más antigua.
Eso es todo. La mayoría de las plantillas de sitios y los CMS ya lo hacen por ti — si el tuyo no, añádelo.
¿Afecta al SEO?
No directamente. La etiqueta charset no es un factor de posicionamiento. Pero si una codificación incorrecta hace que tu texto se vea ilegible, ese contenido roto es lo que ven los usuarios y lo que Google puede acabar indexando y mostrando — así que vale la pena hacerlo bien aunque no te suba en los resultados por sí solo.
¿Quieres los detalles de la especificación — la regla de los “primeros 1024 bytes”, por qué la sintaxis antigua sigue presente y cómo una cabecera del servidor puede anular silenciosamente tu etiqueta? Cambia a la pestaña Avanzado.
Comprueba la codificación declarada desde la línea de comandos
Reemplaza la URL y luego compara la cabecera de respuesta con la etiqueta cerca del inicio del
HTML. Un charset en la cabecera HTTP Content-Type tiene prioridad sobre la declaración
en el documento.
url="https://example.com/"
curl -sSI "$url" | grep -i '^content-type:'
curl -sS "$url" | head -c 1024 | grep -oiE '<meta[^>]+charset[^>]*>'En una consola del navegador, esto informa de la codificación analizada, la etiqueta declarada y
si esa etiqueta es el primer elemento en <head>:
const charset = document.querySelector('meta[charset]');
console.table({
documentCharacterSet: document.characterSet,
declaredCharset: charset?.getAttribute('charset') ?? 'missing',
firstHeadElement: document.head.firstElementChild?.outerHTML ?? 'missing',
charsetIsFirst: document.head.firstElementChild === charset,
});La consola refleja el documento analizado por el navegador. Usa también la comprobación con curl
cuando necesites demostrar lo que el servidor envió realmente.
Inspecciona la respuesta antes de depurar el marcado
Usa el Comprobador de cabeceras HTTP para inspeccionar la cabecera de respuesta
Content-Type en vivo. Si declara un charset, compara ese valor con
<meta charset="utf-8">; un conflicto puede explicar el mojibake incluso cuando la etiqueta HTML
parece correcta.
Para la colocación, usa Ver código fuente en lugar de solo el panel Elementos. Confirma que la
declaración de charset es el primer hijo de <head> y aparece dentro de los primeros
1 024 bytes del documento.
Valida una corrección de charset
Prueba 1 — La cabecera y la etiqueta coinciden
- Hipótesis: La respuesta en vivo y el HTML declaran ambos UTF-8.
- Método: Comprueba la cabecera
Content-Typede la respuesta y luego inspecciona Ver código fuente para<meta charset="utf-8">. - Condición de aprobación: No existe ningún charset declarado por el servidor que entre en conflicto.
- Condición de fallo: La cabecera declara otra codificación o la etiqueta falta.
- Siguiente acción: Corrige primero la cabecera del servidor y luego vuelve a probar la respuesta en vivo.
Prueba 2 — La declaración está lo suficientemente temprana
- Hipótesis: El navegador ve la etiqueta antes de tener que adivinar una codificación.
- Método: Obtener los primeros 1 024 bytes e inspeccionar el inicio de
<head>. - Condición de aprobación: La etiqueta charset completa está dentro de esos bytes y es el primer elemento en
<head>. - Condición de fallo: Los comentarios, scripts inyectados u otro marcado la empujan más adelante.
- Acción siguiente: Mover la etiqueta antes de todo el marcado no esencial de
<head>.
Prueba 3 — Los caracteres reales se renderizan correctamente
- Hipótesis: La corrección elimina el mojibake en el texto visible para el usuario y en el texto indexable.
- Método: Verificar un carácter acentuado, una comilla curva, una raya em, texto no latino y emoji en la página en vivo y en Ver código fuente.
- Condición de aprobación: Cada carácter se renderiza como se escribió después de una actualización forzada.
- Condición de fallo: Quedan glifos de reemplazo o secuencias de bytes corruptas.
- Acción siguiente: Revertir el cambio de codificación si introdujo corrupción, luego rastrear el archivo fuente, la plantilla, la base de datos y el encabezado de respuesta por separado.
TL;DR —
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encoding<meta charset="utf-8">declara la codificación de caracteres del documento. La especificación HTML de WHATWG requiere que la declaración se serialice completamente dentro de los primeros 1024 bytes del documento, y para HTML5 el valor debe coincidir conutf-8; la mejor práctica es colocarla como el primer hijo literal de<head>. Una codificación faltante, tardía o no coincidente produce mojibake — caracteres acentuados corruptos, comillas curvas, escrituras no latinas y emoji — lo cual es un problema de renderizado y corrección de indexación, no una señal de ranking. La única línea pública de Google es “use Unicode/UTF-8 donde sea posible.” Un encabezadoContent-Typeenviado por el servidor con charset anula la etiqueta en el documento, lo cual es un error clásico de mojibake post-migración. Solo se permite un elemento meta charset por documento, y no tiene efecto en XML. Una marca de orden de bytes (BOM) UTF-8, si está presente, gana sobre todo lo demás; de lo contrario, el encabezado HTTP gana sobre la etiqueta en la página — orden de precedencia completo a continuación.
Qué es la etiqueta
La declaración de charset le dice al analizador qué codificación de caracteres usar cuando convierte
los bytes del documento en texto. El WHATWG HTML Living Standard lo dice claramente: “The
charset attribute specifies the character encoding used by the document. This is a
character encoding declaration.” (traducción) «El atributo charset especifica la codificación de caracteres utilizada por el documento. Esta es una declaración de codificación de caracteres.» El enfoque de MDN es la versión práctica: “This
attribute declares the document’s character encoding.” (traducción) «Este atributo declara la codificación de caracteres del documento.»
La sintaxis moderna es la forma corta:
<meta charset="utf-8">También hay una forma heredada pre-HTML5 que aún verás en plantillas más antiguas:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">Ambas declaran lo mismo. En un documento HTML5 moderno solo necesitas la forma corta
<meta charset="utf-8"> — usar ambas es redundante, no dañino, y la especificación permite
solo un elemento meta que declare charset por documento de todos modos. (La forma http-equiv es
mejor considerarla como heredada en lugar de algo nuevo que añadir; si estás auditando una página
que la tiene, no está rota, solo es antigua.)
Los requisitos de la especificación que realmente necesitas saber
UTF-8 es efectivamente obligatorio para HTML5. MDN lo dice directamente: el
“value must be an ASCII case-insensitive match for the string utf-8, because UTF-8
is the only valid encoding for HTML5 documents.” (traducción) «el valor debe coincidir de forma insensible a mayúsculas y minúsculas con la cadena utf-8, porque UTF-8 es la única codificación válida para documentos HTML5.» La especificación WHATWG va más allá y requiere
que la codificación real del documento sea UTF-8 independientemente de lo que se declare.
UTF-8 cubre prácticamente todas las escrituras más emoji, por lo que la era de codificaciones por región
ISO-8859-1 / Windows-1252 / Shift-JIS ha terminado para trabajo nuevo — esas
sobreviven solo como casos de compatibilidad heredados.
Debe estar en los primeros 1024 bytes del documento. Este es un requisito estricto de la especificación, no una sugerencia suave. MDN: “<meta> elements which declare a character encoding must be located entirely within the first 1024 bytes of the document.” (traducción) «Los elementos <meta> que declaran una codificación de caracteres deben ubicarse completamente dentro de los primeros 1024 bytes del documento.» La razón es mecánica: el analizador examina el flujo de bytes para detectar una codificación antes de poder interpretar el resto de manera segura. Si tu declaración aparece demasiado tarde, el analizador puede ya haberse comprometido con una codificación adivinada (o tener que reiniciar, lo que cuesta rendimiento). Observa el encuadre con cuidado: son los primeros 1024 bytes del documento completo, no solo de <head>.
La mejor práctica supera el mínimo de la especificación: haz que sea el primer hijo de <head>. No te conformes con “en algún lugar de los primeros 1024 bytes” — coloca <meta charset="utf-8"> antes de tu <title>, <link>, <script>, <style> y cualquier otra etiqueta. Esta es la ubicación que las herramientas modernas verifican. Hay un problema abierto de Lighthouse (#10023) que propone una auditoría que verifica específicamente si <meta charset> es igual a document.head.firstElementChild — es decir, marcar la etiqueta cuando no es el primer elemento literal en head, no solo cuando falta. La dirección de las herramientas es hacia verificar la ubicación, no solo la presencia.
Solo un elemento meta de charset por documento, y el atributo charset no tiene efecto en documentos XML/XHTML (allí se permite solo para facilitar la migración hacia y desde XML). Vale la pena una advertencia si trabajas con contenido servido como XHTML o plantillas relacionadas con RSS/Atom.
BOM, cabecera HTTP, meta etiqueta — el orden de precedencia
Los navegadores no solo leen la meta etiqueta de forma aislada; el algoritmo de detección de codificación verifica tres fuentes en un orden fijo, y la primera que da una respuesta gana:
- Una marca de orden de bytes UTF-8 (BOM) — unos pocos bytes al inicio del archivo. Si el navegador detecta una BOM, eso determina la codificación con certeza; no se consulta nada más.
- El charset de la cabecera HTTP
Content-Type, si el servidor envía uno y no hay BOM. Esto tiene prioridad sobre la declaración meta dentro del documento. - La declaración
<meta charset>(ohttp-equivheredada) dentro del documento, verificada solo si ninguna de las anteriores proporcionó una codificación.
En la práctica, las BOM son raras en HTML escrito a mano (son más comunes como artefacto de ciertos editores de texto o herramientas de exportación de archivos), por lo que el conflicto entre cabecera y etiqueta es el que afecta con más frecuencia: una página que declara correctamente <meta charset="utf-8"> puede renderizarse con caracteres corruptos si un CDN, un proxy inverso o un servidor mal configurado envía un charset diferente en la cabecera. Es un síntoma clásico justo después de una migración de servidor o CDN: el HTML no cambió, pero la cabecera sí, y ahora la cabecera está en conflicto con la etiqueta. Cuando depures mojibake, verifica la BOM y el charset de la cabecera de respuesta, no solo el código fuente de la página.
¿Es meta charset un factor de ranking SEO?
No — y vale la pena ser directo porque el texto de las herramientas de auditoría basado en el miedo a veces implica lo contrario. Este es un requisito de corrección de renderizado e indexación, no una señal de ranking.
La guía de Google aquí es escasa e indirecta en comparación con las etiquetas que discute constantemente (título, meta descripción, robots, URL principal). No hay una página dedicada de Google Search Central sobre la codificación de caracteres: es una entrada dentro de la referencia general de meta etiquetas que Google admite, bajo “Content-Type y charset”. La única declaración registrada de Google es una recomendación, no una afirmación de ranking: “We recommend using Unicode/UTF-8 where possible.” (traducción) «Recomendamos usar Unicode/UTF-8 cuando sea posible». No aparece ninguna declaración textual de Mueller, Illyes, Splitt o Canel que nombre específicamente “meta charset” o “mojibake” en la prensa especializada o en los archivos de Search Off the Record: el charset se trata como higiene básica de estándares web, algo fundamental como el marcado válido, más que como un tema que merezca comentarios de SEO.
Bing tampoco tiene una posición pública distinta sobre la etiqueta en la página; su documentación hace referencia a UTF-8 solo para sus propios formatos de API/feed (archivos de clave de IndexNow, encabezados de solicitud de Webmaster API), no como orientación sobre el <meta charset> HTML en tus páginas. Dado que Bingbot es un analizador HTML estándar, la implicación práctica es la misma: sigue la regla de UTF-8 / 1024 bytes de la especificación HTML.
Entonces, ¿dónde puede perjudicarte? Indirectamente, y solo cuando la codificación está realmente rota: el texto ilegible es un problema de calidad de contenido y de experiencia de usuario, puede corromper lo que aparece en los fragmentos, y una salida gravemente rota puede parecer rota también para los sistemas de indexación de Google. El consenso de la industria, como lo expresa la propia guía de meta etiquetas de Ahrefs (de Joshua Hardwick), es que “a menos que tu página esté gravemente rota como resultado de problemas de charset (lo cual es poco probable), el impacto va a ser bastante mínimo.” Arrégialo porque el texto roto es malo, no porque esperes un aumento en el ranking.
Cómo comprobarlo y solucionarlo
Una ruta de diagnóstico rápida cuando sospechas un problema de codificación:
- Ver código fuente / DevTools. Confirma que
<meta charset="utf-8">existe y es el primer hijo de<head>. En DevTools, comprueba el encabezado de respuestaContent-Typepara un valor de charset — si no coincide con la etiqueta, el encabezado gana y es tu probable culpable. Descarta también un BOM: es más raro, pero si está presente, supera tanto al encabezado como a la etiqueta. - Los validadores y rastreadores lo señalan. El validador W3C y los verificadores basados en reglas (p. ej., la regla de Rocket Validator sobre “charset después de los primeros 1024 bytes”) señalarán una declaración tardía o ausente. Las auditorías de sitio en Ahrefs Site Audit y Screaming Frog sacan a la luz problemas de charset en todo un sitio.
- Arregla la capa correcta. Si la ubicación es incorrecta, mueve la etiqueta al principio de head.
Si la codificación es incorrecta (los bytes en sí no son UTF-8, o el encabezado envía un
charset conflictivo), arreglar solo la meta etiqueta no ayudará — tienes que volver a codificar el
archivo como UTF-8 y/o corregir el encabezado
Content-Typedel servidor para que el encabezado y la etiqueta coincidan.
La solución es casi siempre trivial una vez que has identificado qué capa tiene la culpa. Esta es una parte estable y consolidada de la especificación HTML — no hay ninguna desaprobación reciente ni cambio de comportamiento de plataforma que seguir; el único matiz en evolución es que las herramientas comprueban cada vez más la ubicación, no solo la presencia.
Dónde encaja esto
La etiqueta de charset es uno de los elementos de head orientados al navegador — como la etiqueta de viewport, se trata de renderizado, no de ranking, lo que la coloca en una categoría diferente de las etiquetas activas para SEO en el grupo de meta etiquetas (el elemento title, la meta descripción y la familia robots). Está adyacente al trabajo de internacionalización en el que paso mucho tiempo: la codificación es la capa debajo de hreflang y el contenido multiescritura — hreflang le dice a Google qué versión de idioma/región servir, pero si la codificación es incorrecta, el texto en esa versión está ilegible independientemente. Para el mapa completo de elementos de head agrupados por el trabajo que hacen, consulta el centro de meta etiquetas.
Resumen de IA
Una versión condensada de la versión avanzada:
- Qué es:
<meta charset="utf-8">declara la codificación de caracteres del documento para que los navegadores y rastreadores asignen los bytes sin procesar a los caracteres correctos. - Reglas de especificación: la declaración debe estar dentro de los primeros 1024 bytes de todo el
documento; HTML5 requiere que el valor sea
utf-8(y que la codificación real sea UTF-8). Mejores prácticas: el literal primer hijo de<head>. Solo un elemento meta de charset por documento; no tiene efecto en XML/XHTML. - Sintaxis heredada:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">es la forma anterior a HTML5 — redundante en páginas modernas; usa la forma corta. No necesitas ambas. - Orden de precedencia: un BOM UTF-8, si está presente, tiene prioridad sobre todo; de lo contrario, un
Content-Typeenviado por el servidor anula la etiqueta en la página — un clásico error de mojibake posterior a la migración. Depura el encabezado (y verifica si hay un BOM), no solo el código fuente. - Por qué importa: una codificación faltante/tardía/incorrecta causa mojibake (acentos distorsionados, comillas curvas, escrituras no latinas, emoji) — un problema de corrección de renderizado/indexación, no un factor de clasificación.
- Lo que dice Google: solo una línea indirecta — “We recommend using Unicode/UTF-8 where possible.” (traducción) «Recomendamos usar Unicode/UTF-8 cuando sea posible». Sin documento dedicado, sin cita de representante sobre charset/mojibake. Bing no tiene una posición distinta en la página. El marco de la industria (Ahrefs): el impacto es mínimo a menos que la página esté “gravemente rota”.
- Diagnóstico: ver código fuente/DevTools para la etiqueta y el charset del encabezado de respuesta; los validadores (W3C, Rocket Validator) y las auditorías de sitios (Ahrefs, Screaming Frog) marcan declaraciones tardías o faltantes. Corrige la capa correcta: ubicación vs. codificación/encabezado real.
Documentación oficial
Documentación de fuentes primarias y especificaciones.
Estándares (WHATWG / MDN)
- Estándar HTML (WHATWG) — Especificar la codificación de caracteres del documento — las reglas normativas: la declaración de charset, el requisito de los primeros 1024 bytes, UTF-8, el límite de una por documento y la excepción XML.
- Estándar HTML (WHATWG) — Determinar la codificación de caracteres — el algoritmo de detección de codificación: detección de BOM primero, luego el
Content-Typea nivel HTTP, luego la declaración meta en el documento. - MDN —
<meta>: el elemento de metadatos — referencia en lenguaje sencillo: soloutf-8para HTML5, la regla de 1024 bytes y la forma heredadahttp-equiv.
- Metaetiquetas y atributos HTML que Google admite — la única guía de Google que toca el charset, bajo “Content-Type y charset”: las formas aceptadas de
http-equivycharsety la recomendación de “usar Unicode/UTF-8 cuando sea posible”.
Bing / Microsoft
- IndexNow — primeros pasos — Bing hace referencia a UTF-8 solo para sus propios formatos de API/archivo de clave, no como guía HTML en la página. No hay un documento dedicado de Bing sobre la etiqueta
<meta charset>.
Herramientas
- Problema de Lighthouse #10023 — advertir sobre
<meta charset>tardío o faltante — la auditoría propuesta que verifica si la etiqueta de charset esdocument.head.firstElementChild.
Citas de la fuente
Declaraciones registradas de la especificación HTML, MDN y Google. Cada enlace es un enlace profundo que salta al pasaje citado cuando la fuente lo admite.
Estándar HTML WHATWG — qué es la etiqueta
- “El atributo
charsetespecifica la codificación de caracteres utilizada por el documento. Esta es una declaración de codificación de caracteres.” — Estándar HTML Living (WHATWG). Fuente
MDN — las reglas de codificación y ubicación
- “This attribute declares the document’s character encoding. If the attribute is present, its value must be an ASCII case-insensitive match for the string
utf-8, because UTF-8 is the only valid encoding for HTML5 documents.<meta>elements which declare a character encoding must be located entirely within the first 1024 bytes of the document.” (traducción) «Este atributo declara la codificación de caracteres del documento. Si el atributo está presente, su valor debe coincidir de forma insensible a mayúsculas y minúsculas en ASCII con la cadenautf-8, porque UTF-8 es la única codificación válida para documentos HTML5. Los elementos<meta>que declaran una codificación de caracteres deben ubicarse completamente dentro de los primeros 1024 bytes del documento.» — MDN Web Docs, «<meta>: el elemento de metadatos». Ir a la cita
Google — la posición oficial (limitada)
- “These tags define the page’s content type and character set respectively. Make sure that you surround the value of the
contentattribute in thehttp-equivmetatag with quotes—otherwise thecharsetattribute may be interpreted incorrectly. We recommend using Unicode/UTF-8 where possible.” (traducción) «Estas etiquetas definen el tipo de contenido y el conjunto de caracteres de la página, respectivamente. Asegúrate de rodear el valor del atributocontenten la etiquetametahttp-equivcon comillas; de lo contrario, el atributocharsetpodría interpretarse incorrectamente. Recomendamos usar Unicode/UTF-8 cuando sea posible.» — Google Search Central, “Meta tags and attributes that Google supports.” (traducción) «Metaetiquetas y atributos compatibles con Google». Ir a la cita
Industria — el encuadre honesto del impacto SEO
- “Unless your page is severely broken as a result of charset issues (which is unlikely), the impact is going to be quite minimal.” (traducción) «A menos que tu página esté gravemente rota debido a problemas de codificación de caracteres (lo cual es poco probable), el impacto será bastante mínimo.» — Blog de Ahrefs, «Metaetiquetas para SEO: guía sencilla para principiantes» (Joshua Hardwick). Fuente
Auditoría de meta charset — lista de verificación
Una pasada rápida para confirmar que tus páginas declaran y renderizan la codificación correctamente:
- Cada página tiene
<meta charset="utf-8">en el<head>. - La etiqueta de charset es el primer hijo de
<head>— antes de<title>,<link>,<script>,<style>y cualquier otro<meta>. - La declaración se encuentra dentro de los primeros 1024 bytes del documento (lo estará si es el primer hijo del head).
- El valor es
utf-8— no ISO-8859-1, Windows-1252 ni una página de códigos por región. - El archivo en sí está realmente guardado/servido como UTF-8 (la declaración y la codificación real de bytes deben coincidir).
- Solo un elemento meta de charset por página.
- El encabezado de respuesta
Content-Typedel servidor coincide con el charset de la etiqueta (el encabezado gana sobre la etiqueta si entran en conflicto) — verifica en DevTools, especialmente después de cualquier migración de CDN o servidor. - Sin marca de orden de bytes (BOM) UTF-8 extraviada al inicio del archivo — rara, pero si está presente, tiene prioridad sobre el encabezado y la etiqueta.
- Verifica puntualmente páginas con contenido no ASCII (acentos, comillas curvas, escrituras no latinas, emojis) — el inglés simple puede verse bien incluso cuando la codificación está rota.
- Ejecutó la página a través del validador W3C / un rastreador (Ahrefs Site Audit, Screaming Frog) para detectar declaraciones tardías o faltantes a escala.
- No agregues la forma heredada
http-equiv="Content-Type"en trabajo nuevo — el corto<meta charset="utf-8">es suficiente.
Hoja de referencia de meta charset
Las dos sintaxis
| Forma | Sintaxis | ¿Usarla? |
|---|---|---|
| Moderna (HTML5) | <meta charset="utf-8"> | Sí — esto es lo que quieres |
| Heredada (pre-HTML5) | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | No para trabajo nuevo; redundante, solo se necesita una |
Las reglas que importan
| Regla | Detalle |
|---|---|
| Valor | Debe ser utf-8 para HTML5 (la especificación también requiere que la codificación real sea UTF-8) |
| Ubicación (mínimo de la especificación) | Dentro de los primeros 1024 bytes del documento |
| Ubicación (buena práctica) | El primer hijo literal de <head> |
| Cantidad | Un elemento meta de charset por documento, no más |
| XML/XHTML | El atributo charset no tiene efecto en documentos XML |
| Precedencia | Un BOM UTF-8 gana sobre todo; de lo contrario, un encabezado Content-Type del servidor con charset anula la etiqueta en la página |
Datos rápidos
- Codificación incorrecta, ausente o tardía → mojibake (acentos corruptos, comillas curvas, escrituras no latinas, emojis). El inglés ASCII simple puede verse bien igualmente: el error se oculta.
- No es un factor de clasificación. La única línea de Google: “use Unicode/UTF-8 where possible.” (traducción) «usa Unicode/UTF-8 cuando sea posible».
- El impacto es mínimo a menos que la página esté gravemente rota (Ahrefs), pero el texto roto sigue valiendo la pena corregirlo para los usuarios y la indexación.
- ¿Depurando mojibake? Comprueba primero si hay un BOM y luego el charset del encabezado de respuesta, no solo el código fuente de la vista: el BOM supera al encabezado, y el encabezado supera a la etiqueta.
- Las herramientas se están moviendo hacia comprobar la ubicación (primer hijo de head), no solo la presencia (ver Lighthouse #10023).
Ponte a prueba: la etiqueta Meta Charset
Cinco preguntas rápidas sobre la codificación de caracteres y la etiqueta charset. Elige una respuesta para cada una y luego comprueba.
Registro de cambios
Actualizado el 11 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 18 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.