¿Qué son los shortcodes de WordPress? Una guía práctica

Los shortcodes de WordPress son fragmentos cortos de texto envueltos en corchetes (como [contact-form] o [gallery ids="1,2,3"]) que WordPress reemplaza por contenido dinámico al renderizar una entrada o página. Se introdujeron en WordPress 2.5 (2008) y se convirtieron durante más de una década en la forma dominante en que los plugins añadían salida compleja al contenido. Desde el despliegue del editor de bloques Gutenberg en WordPress 5.0 (2018), los shortcodes tienen un sucesor: los bloques. Pero los shortcodes no van a desaparecer. Siguen funcionando, millones de sitios dependen de ellos, y muchos plugins los siguen distribuyendo junto a o en lugar de bloques.

¿Cómo se ve un shortcode de WordPress?

El shortcode básico es un nombre entre corchetes:

[gallery]

WordPress lo ve en el contenido de la entrada, busca el handler registrado para gallery, ejecuta la función PHP, y reemplaza la etiqueta por el HTML que el handler emita. El visitante ve una galería; el editor ve [gallery].

Los shortcodes pueden tomar parámetros (llamados atributos):

[gallery ids="42,43,44" columns="3" link="file"]

Y pueden envolver contenido (llamados shortcodes envolventes):

[highlight color="yellow"]Texto importante[/highlight]

El handler del shortcode recibe los atributos y el contenido interno, los procesa en PHP, y devuelve el HTML para insertarlo en la página. El visitante nunca ve los corchetes; ve la salida renderizada.

¿Cuál es la diferencia entre un shortcode y un bloque de Gutenberg?

Ambos producen contenido dinámico; difieren en dónde y cómo se genera ese contenido.

• Los shortcodes son del lado servidor. La etiqueta entre corchetes queda en el contenido de la entrada almacenado en la base de datos. Cuando se solicita la página, WordPress parsea el contenido, encuentra el shortcode, ejecuta el handler PHP, y sustituye la salida. La vista del editor siempre muestra la sintaxis cruda con corchetes.
• Los bloques se almacenan como HTML renderizado (con comentarios de metadatos). Cuando guardas una entrada en el editor de bloques, el plugin del bloque genera el HTML final y lo almacena en la base de datos. El editor muestra una vista previa en vivo del bloque renderizado, no una etiqueta. En el frontend, no se ejecuta PHP para renderizar la mayoría de los bloques; el HTML se sirve directamente.

Consecuencias prácticas:

• Rendimiento. Los bloques son más rápidos en el frontend porque no hay paso de parseo y reemplazo. Los shortcodes desencadenan un escaneo con regex de cada entrada en cada render.
• Experiencia de edición. Los bloques muestran cómo se verá la salida renderizada mientras editas. Los shortcodes solo muestran la etiqueta; previsualizas el resultado.
• Portabilidad. Si desactivas el plugin que provee un bloque, el HTML almacenado normalmente sigue visible (congelado en la versión cuando se guardó por última vez). Si desactivas el plugin que provee un shortcode, la etiqueta entre corchetes queda en el contenido como texto plano, lo que normalmente se ve roto.
• Reutilizabilidad. Los shortcodes se pueden añadir en cualquier sitio donde se ejecute PHP, incluyendo widgets, plantillas y extractos. Los bloques están diseñados para el área del editor de bloques, aunque los "Bloques Reutilizables" y el movimiento FSE (full-site editing) están cerrando esa brecha.

¿Qué shortcodes integrados de WordPress siguen incluidos en el core?

El core de WordPress ha enviado históricamente un puñado de shortcodes. A 2026, los supervivientes en el codebase:

• [gallery] — Galería de imágenes. Aún la usa el editor clásico y como fallback cuando se convierte el bloque Galería.
• [caption] — Envuelve una imagen con un pie de foto. Mayormente reemplazado por el bloque Imagen pero todavía emitido en algunos flujos.
• [audio] y [video] — Reproductor HTML5 nativo para medios auto-hospedados.
• [embed] — Fuerza que una URL se incruste vía el handler oEmbed. Raramente necesario porque WordPress autoincrusta la mayoría de URLs.
• [playlist] — Playlists de audio y vídeo. Uso de nicho.

La gran mayoría de los shortcodes en cualquier sitio WordPress real vienen de plugins y temas, no del core.

¿Qué tipos de plugins usan shortcodes?

Cinco categorías cubren casi todo el uso real de shortcodes:

• Formularios de contacto. Contact Form 7 ([contact-form-7 id="123"]), WPForms, Gravity Forms y Formidable exponen formularios vía shortcodes. Aun cuando estos plugins también ofrecen bloques de Gutenberg, el shortcode sigue siendo soportado por compatibilidad hacia atrás.
• E-commerce. WooCommerce usa shortcodes para Carrito, Checkout, Mi Cuenta y listados de productos ([products limit="4"]). El editor de bloques ahora tiene bloques equivalentes, pero los shortcodes siguen dominando porque la mayoría de los temas se construyeron en torno a ellos.
• Page builders (en modo legacy). Los antiguos Visual Composer, WPBakery y similares producen shortcodes masivos anidados cuando se usan en el editor clásico. Apagar el page builder deja una pared de etiquetas [vc_row][vc_column]... como texto plano en la entrada, un famoso problema de lock-in.
• Tablas de precios, sliders, acordeones. La mayoría de plugins de "widgets de contenido" (Soliloquy, Smart Slider, Easy Pricing Tables) históricamente se distribuían como shortcodes. Muchos siguen activamente mantenidos pero han añadido bloques.
• Sitios de membresía y aprendizaje. MemberPress, LearnDash y similares restringen contenido con envolturas de shortcode como [restrict role="member"]...[/restrict].

¿Cómo funciona realmente un shortcode por dentro?

Tres líneas de código de plugin crean un shortcode. Este ejemplo mínimo registra un shortcode que emite un resaltado amarillo:

add_shortcode('highlight', function ($atts, $content = null) {
    $atts = shortcode_atts([
        'color' => 'yellow',
    ], $atts, 'highlight');

    return '<mark style="background:' . esc_attr($atts['color']) . '">' . do_shortcode($content) . '</mark>';
});

Lo que ocurre cuando WordPress renderiza [highlight color="pink"]Hola[/highlight]:

1. WordPress ejecuta el filtro the_content, que incluye do_shortcode().
2. do_shortcode() usa una regex para encontrar etiquetas de shortcode en el contenido de la entrada.
3. Para cada coincidencia, llama al handler registrado con los atributos (['color' => 'pink']) y el contenido interno ('Hola').
4. El handler devuelve un string, que reemplaza la etiqueta del shortcode en la salida.
5. El contenido de la entrada se renderiza luego al navegador con la etiqueta sustituida.

El parseo con regex en cada render de entrada es el coste de rendimiento. En un sitio con miles de entradas, sin caché y con shortcodes en cada entrada, eso se acumula. Una caché de página (Redis, WP Super Cache) lo soluciona almacenando el HTML final renderizado y saltándose el parseo.

¿Cuándo debería seguir usando shortcodes en 2026?

Tres casos legítimos:

• Compatibilidad hacia atrás. Si tu sitio ya usa shortcodes de Contact Form 7, WooCommerce o cualquier plugin establecido, sigue usándolos. Convertir masivamente entradas viejas a bloques es un proyecto de varios días con poco rédito.
• Fuera del editor de bloques. Widgets (en áreas de widgets clásicas), extractos, loops de tipos de entrada personalizados, contenido de page builders, y emails enviados vía plantillas de Mailchimp siguen aceptando shortcodes pero no bloques. Los shortcodes funcionan en cualquier contexto donde se pueda llamar a do_shortcode().
• Plantillas y código de tema. Poner echo do_shortcode('[my-form id="3"]'); en una plantilla PHP es una forma de una línea de inyectar salida de plugin. Los bloques requerirían renderizado de bloque del lado servidor, que es más código.

Para funcionalidad genuinamente nueva en un sitio nuevo, prefiere los bloques. Son la dirección del core de WordPress, tienen una mejor experiencia de edición, y evitan la sobrecarga del parseo de shortcodes.

¿Qué es el "shortcode bloat" y por qué importa?

El shortcode bloat ocurre cuando un sitio depende de docenas de shortcodes de plugins inactivos o desactivados. Siguen dos modos de fallo:

• Plugin desactivado pero las etiquetas siguen. Desactivas un plugin de slider para probar algo. Cada página que tenía [slider id="3"] ahora muestra el texto literal "[slider id="3"]" en vez de un slider. El arreglo es reactivar el plugin o eliminar manualmente todas las etiquetas de shortcode de la base de datos, lo cual es tedioso.
• Migración de page builder. Un sitio construido en Visual Composer o WPBakery contiene shortcodes anidados como [vc_row][vc_column width="1/2"][vc_column_text]Hola[/vc_column_text][/vc_column][/vc_row]. Cambiar de tema o desactivar el builder revela todo esto como texto plano. Esta es la fuente del punto de dolor "no puedo migrar mi sitio a Gutenberg" que ha atrapado a miles de sitios.

La prevención pragmática: elegir plugins a los que te comprometas a largo plazo, y preferir plugins que también soporten bloques para poder migrar gradualmente. Para sitios construidos antes de 2018, espera un proyecto de migración real en vez de un cambio limpio.

¿Puedo crear mi propio shortcode sin escribir un plugin?

Sí, tres maneras:

1. En el functions.php de un child theme. Añade la llamada add_shortcode(). El shortcode queda disponible en todo el sitio. Funciona pero el shortcode queda atado a ese tema; cambia de tema y el shortcode desaparece.
2. En un mu-plugin personalizado. Crea wp-content/mu-plugins/my-shortcodes.php y pon ahí tus llamadas add_shortcode(). Sobrevive cambios de tema y la mayoría de actualizaciones. La solución más limpia.
3. Vía un plugin "Code Snippets". Plugins como Code Snippets o WPCode te permiten añadir PHP a través de la UI de admin. Cómodo si no puedes editar archivos, pero añade una dependencia a nivel admin para código que idealmente vive en archivos.

¿Cuáles son los errores comunes con shortcodes?

• Olvidar do_shortcode() en el contenido interno. Si tu shortcode envuelve contenido (shortcode envolvente), deberías llamar a do_shortcode($content) en la parte interna para que funcionen los shortcodes anidados. Sin eso, [outer][inner][/outer] renderiza solo el shortcode exterior y deja [inner] como texto plano.
• Hacer echo dentro del handler. Los handlers de shortcode deben devolver su salida, no hacerle echo. Un shortcode echoado se renderiza antes del contenido en el que está embebido, rompiendo el layout de la página de formas sutiles.
• Olvidar esc_attr() en los atributos. Sin escape, los valores de atributo provistos por el usuario pueden salirse del HTML y crear vulnerabilidades XSS. Escapea siempre lo que emites.
• Shortcodes en widgets que no los ejecutan. Algunos tipos de widget clásicos (como el Text widget básico pre-WordPress 4.9) no auto-ejecutan shortcodes. Arreglo: add_filter('widget_text', 'do_shortcode');.
• Etiquetas dentro de otras etiquetas que confunden el parseo. Un atributo de shortcode que contiene un carácter de corchete ([shortcode label="Click [here]"]) confunde al parser. WordPress maneja muchos casos pero no todos; usar entidades HTML ([ y ]) es el workaround seguro.
• Añadir do_shortcode recursivamente. Dentro de un handler de shortcode, llamar a do_shortcode() en contenido que contiene el mismo shortcode crea un bucle infinito. WordPress tiene salvaguardas, pero el síntoma es una página en blanco o un error de memoria agotada.

¿Cómo encuentro cada shortcode usado en mi sitio?

Tres enfoques rápidos:

1. Búsqueda en base de datos. Ejecuta una consulta SQL contra wp_posts: SELECT DISTINCT REGEXP_SUBSTR(post_content, '\\[[a-z_-]+') FROM wp_posts WHERE post_status = 'publish';. Lista cada etiqueta de shortcode que aparece en contenido publicado.
2. WP-CLI. wp shortcode list muestra cada handler de shortcode registrado. Compara con la lista de la base de datos para encontrar shortcodes que se usan pero ya no tienen un handler activo (probablemente de un plugin desactivado).
3. Plugins tipo "Shortcode Cleaner" o "Find My Blocks". Escanean el contenido en busca de uso de shortcodes y bloques. Útil antes de desactivar un plugin para ver qué tan ampliamente se usan sus shortcodes.

¿Qué hay de la seguridad?

Los shortcodes en sí no son inseguros; la cuestión es qué hace el handler con los atributos. Dos modelos de amenaza:

• Un usuario no confiable envía contenido que contiene shortcodes. Si un colaborador o suscriptor puede enviar entradas y el shortcode ejecuta código del lado servidor (como [exec command="..."] de un plugin de desarrollo), eso es una vía de ejecución de código arbitrario. El core de WordPress quita los shortcodes del contenido enviado por usuarios con bajos privilegios por defecto; no deshagas esta protección.
• Los atributos del shortcode se emiten de forma insegura. Un shortcode mal escrito podría hacer echo de [badge text="..."] directamente en la página sin escape, permitiendo a un admin que edita una entrada inyectar etiquetas script. Mantén la edición de entradas solo para admins, y escapea siempre los valores de atributo al escribir shortcodes personalizados.

Qué verifica InspectWP

Los shortcodes no son parte directa de un reporte de seguridad o rendimiento de InspectWP, pero sus efectos aparecen en varios sitios. Un sitio con shortcodes de plugins desactivados típicamente tiene hallazgos de "layouts rotos" (texto renderizado con corchetes). Un sitio con uso intensivo de shortcodes sin caché de página aparece como TTFB lento. Y un sitio donde shortcodes de Visual Composer o WPBakery se filtran al HTML renderizado (porque el page builder está roto o desactivado) aparece como errores de render y violaciones de accesibilidad. El patrón recomendado en 2026 es seguir usando shortcodes por razones legacy, preferir bloques para contenido nuevo, y auditar tu sitio periódicamente por shortcodes cuyos handlers ya no estén registrados.