Saber cómo pegar un código correctamente es una de esas habilidades que nadie te enseña pero que necesitas en cuanto trabajas con una web, un formulario de contacto, un píxel de seguimiento o simplemente quieres incrustar un vídeo. El problema no es copiar: es pegar en el sitio equivocado y que el código no haga nada, o peor, que rompa el diseño. Esta guía cubre los casos más habituales, desde WordPress hasta Google Docs, con el procedimiento exacto para cada uno y los errores que debes evitar antes de guardar los cambios.
Un fragmento de código no es texto normal. Puede ser HTML (la estructura de una página), JavaScript (comportamiento interactivo), un píxel de analítica o un bloque de seguimiento de campañas. Cada tipo tiene su lugar exacto dentro de un documento o página web, y pegarlo en el lugar equivocado produce desde que no funcione hasta que tu página deje de cargar.
Antes de pegar cualquier código, hazte estas tres preguntas:
Quien te proporciona el código (Google Tag Manager, YouTube, un formulario de HubSpot) suele indicar dónde debe ir. Si no lo indica, el comportamiento habitual es: los scripts de seguimiento van en el <head> y los contenidos incrustados van en el <body>, justo donde quieres que aparezcan.
Imagina una tienda online de ropa que quiere añadir el píxel de Meta para hacer retargeting. Si lo pega en el cuerpo de la página en lugar de en el encabezado, el píxel puede cargarse tarde o no cargarse en todas las páginas. El resultado: datos de conversión incompletos en el Administrador de anuncios. El procedimiento correcto habría sido pegarlo en la sección <head> del tema, o mejor, usar un gestor de etiquetas que lo inyecte automáticamente.
WordPress tiene dos editores con comportamientos muy distintos: el editor de bloques (Gutenberg, activo desde la versión 5.0) y el editor clásico. Usar el bloque equivocado es el error más habitual, y la señal más clara de que algo ha ido mal es ver el código escrito como texto plano en tu página, en lugar de ver el elemento que debería mostrar.
El editor de bloques de WordPress tiene un bloque específico para esto. No uses el bloque de párrafo: nunca interpretes HTML pegado en texto plano.
Si el bloque muestra el código como texto en lugar de renderizarlo, comprueba que no hayas pegado el contenido en un bloque de párrafo por error. Elimina ese bloque, crea uno de HTML personalizado y vuelve a intentarlo.
Algunos códigos deben estar en el <head> de todas las páginas: el píxel de seguimiento de Meta, el script de Google Analytics o los fragmentos de verificación de Google Search Console. Para estos casos, el bloque de HTML personalizado no sirve porque solo afecta a una página concreta.
Las opciones más habituales son:
La recomendación actual es usar Google Tag Manager si ya gestionas varios scripts. Si solo tienes uno o dos, un plugin de cabeceras es más rápido y menos propenso a errores.
Al copiar código desde un PDF, un correo electrónico o un procesador de texto como Word, es habitual que los caracteres especiales se conviertan en entidades HTML incorrectas o en símbolos extraños. Las comillas tipográficas (“ ”) sustituyen a las rectas (" "), y esto rompe cualquier script.
Antes de pegar en WordPress, pasa siempre el código por un editor de texto plano (Notepad en Windows, TextEdit en Mac con formato sin estilo activado). Esto elimina el formato oculto. Después, copia desde ahí y pega en el bloque de HTML personalizado. Si el código sigue sin funcionar, abre las herramientas de desarrollador del navegador (F12) y revisa la consola: los errores de JavaScript aparecen ahí con la línea exacta que falla.
Cuando trabajas directamente con archivos HTML, sin ningún CMS de por medio, el proceso es más limpio pero exige saber exactamente dónde colocar cada fragmento dentro del documento.
Un archivo HTML tiene una estructura fija:
Si alguien te da un código para incrustar un mapa de Google Maps, debes pegarlo dentro del <body>, en la posición exacta donde quieres que aparezca el mapa. Si te dan un script de analítica, va justo antes del cierre de </head>.
Para editar el archivo, usa un editor de código como Visual Studio Code o Notepad++, nunca Word o el bloc de notas estándar de Windows, porque pueden añadir caracteres invisibles que corrompen el código. Guarda el archivo en formato UTF-8 para evitar problemas con caracteres especiales en español.
Pegar código en el lugar incorrecto del HTML no siempre rompe la página: a veces simplemente hace que el elemento no aparezca, y eso es más difícil de diagnosticar que un error visible.
Si usas un editor online como CodePen o JSFiddle para probar código antes de subirlo a tu web, ten en cuenta que estos entornos ya gestionan el <head> y el <body> por ti. Solo pegas el fragmento relevante en el panel correspondiente (HTML, CSS o JS) y el editor lo compila automáticamente.
Word y Google Docs no ejecutan código: lo muestran como texto. El reto aquí no es que funcione, sino que se vea legible, con una tipografía monoespaciada que lo distinga del texto normal y sin que el procesador de texto cambie comillas, guiones o saltos de línea.
Word no tiene un bloque de código nativo equivalente al de Notion o Google Docs, así que hay varias aproximaciones con resultados distintos:
El error más común al pegar código en Word es que el autocorrector cambie automáticamente las comillas rectas por tipográficas o ponga en mayúscula la primera letra de una línea. Desactiva la autocorrección antes de pegar: ve a Archivo > Opciones > Revisión > Opciones de autocorrección y desmarca las casillas de reemplazar texto mientras escribes.
Google Docs incorpora desde hace un tiempo un bloque de código nativo. Para usarlo:
Google Docs aplica automáticamente el resaltado de sintaxis según el lenguaje seleccionado. Si pegas código fuera del bloque, el documento lo tratará como texto plano y el autocorrector puede alterar el contenido, especialmente en fragmentos con guiones o comillas.
La mayoría de los problemas al insertar un fragmento de código tienen una causa común: el código ha pasado por un intermediario (un correo, un PDF, un procesador de texto) que ha alterado su formato original. Conocer los síntomas te permite diagnosticar el problema sin necesidad de revisar el código línea a línea.
| Síntoma | Causa probable | Solución |
|---|---|---|
| El código aparece como texto en la página | Pegado en un bloque de párrafo, no en HTML personalizado | Usar el bloque de HTML personalizado en WordPress o el modo fuente en el editor |
| El script no se ejecuta | Comillas tipográficas o caracteres corruptos | Pasar por un editor de texto plano antes de pegar |
| El diseño se rompe tras pegar | Una etiqueta sin cerrar o código pegado fuera de su contenedor | Revisar el HTML con las herramientas de desarrollador (F12) y buscar etiquetas huérfanas |
| El elemento incrustado aparece pero no funciona | El script depende de otro archivo que no se ha cargado | Comprobar la consola del navegador para ver qué recurso falla |
| El código funciona en local pero no en producción | Diferencias de protocolo (http vs https) o bloqueo por política de seguridad | Asegurarse de que todos los recursos del script usan https |
Olvídate de revisar el código visualmente carácter a carácter: las herramientas de desarrollador del navegador (F12 en Chrome o Firefox) muestran los errores exactos en la pestaña Consola. Un error de tipo Uncaught SyntaxError indica un problema en el propio código; un error de tipo Failed to load resource apunta a un archivo externo que no se puede alcanzar.
Pegar directamente en producción, sin validar antes, es el error que más tiempo cuesta en proyectos reales. Si el código es un script de analítica o un píxel de seguimiento, un fallo puede significar días de datos perdidos. Si es HTML estructural, puede afectar al rastreo que hace Google de tu página.
El procedimiento para validar antes de publicar depende del tipo de código:
El W3C (World Wide Web Consortium) mantiene un validador gratuito en línea que analiza fragmentos de HTML y señala errores de sintaxis. El procedimiento es:
Una etiqueta sin cerrar o un atributo mal formado no siempre rompe la página visualmente, pero puede afectar a cómo Google interpreta el contenido. Los navegadores modernos corrigen muchos errores de HTML por su cuenta, así que lo que ves en pantalla puede parecer correcto aunque el código tenga fallos.
Para scripts de JavaScript o píxeles de seguimiento, el validador del W3C no es suficiente. El flujo de comprobación es:
Un código que no produce errores en consola no garantiza que esté funcionando: comprueba siempre que el dato llega a la herramienta de destino, no solo que el script se carga.
Si trabajas con Google Tag Manager, el modo Vista previa de GTM te muestra en tiempo real qué etiquetas se han disparado en cada página y en qué orden, sin necesidad de publicar los cambios. Es la forma más segura de verificar antes de activar cualquier script en producción. Cuando el diagnóstico confirme que todo funciona, publica el contenedor y da por cerrado el proceso.
El código en sí no genera penalizaciones, pero sí puede causar problemas indirectos. Un script mal pegado que ralentiza la carga afecta a las métricas de experiencia de página que Google valora. Un código que rompe el HTML puede dificultar el rastreo de tu contenido. La clave es validar antes de publicar y comprobar que la velocidad no se deteriora tras añadir el fragmento.
Depende del tipo de código y del lugar donde va. Incrustar un vídeo de YouTube o un formulario en WordPress con el bloque de HTML personalizado está al alcance de cualquiera. Modificar el archivo functions.php o editar el <head> del tema directamente requiere precaución: un error puede dejar el sitio inaccesible. Para estos casos, usa un plugin de gestión de cabeceras o Google Tag Manager.
Lo primero es deshacer el cambio: en WordPress, ve al historial de revisiones de la página o del tema y restaura la versión anterior. Si editaste un archivo directamente, restaura la copia de seguridad que (esperemos) hiciste antes. Una vez recuperada la página, revisa el código en un editor de texto plano y valídalo antes de intentarlo de nuevo.
Los motivos más habituales son dos: que la página en producción use HTTPS y el recurso que carga el script use HTTP (el navegador lo bloquea por política de seguridad mixta), o que haya un plugin de caché que sirve una versión antigua de la página. Limpia la caché tras publicar y comprueba que todos los recursos del script usan HTTPS.
Desactiva el autocorrector antes de pegar: ve a Archivo > Opciones > Revisión > Opciones de autocorrección y desmarca los reemplazos automáticos. Luego pega el código en un cuadro de texto con fuente monoespaciada como Consolas o Courier New. Esto evita que Word cambie comillas, guiones o mayúsculas automáticas que rompen la legibilidad del fragmento.
Los scripts de analítica y píxeles de seguimiento deben aparecer en todas las páginas del sitio, no solo en una. La forma más eficiente de hacerlo es añadirlos al <head> global del tema, usando un plugin de gestión de cabeceras o Google Tag Manager. Pegar el código página a página es inviable y propenso a errores u omisiones.
Sí, y es relevante. WordPress.com en sus planes básicos restringe la inserción de código JavaScript y HTML personalizado por motivos de seguridad. WordPress autoalojado (el software descargado de WordPress.org) te da acceso completo al código, los archivos del tema y los plugins. Si necesitas pegar scripts de terceros con frecuencia, el plan de WordPress.com debe ser Business o superior.