Temas hijo de WordPress: ¿siguen siendo relevantes en la era de los bloques?

Los temas hijo de WordPress han sido durante más de una década una de las formas más seguras de personalizar un sitio sin modificar directamente el tema original. Sin embargo, con la llegada de los temas de bloques, la edición completa del sitio (Full Site Editing o FSE) y un Editor del sitio cada vez más completo, es razonable preguntarse si siguen siendo necesarios en 2026.

La respuesta corta es sí, aunque no para todos los sitios. Los temas hijo continúan siendo especialmente útiles cuando se necesitan personalizaciones duraderas basadas en archivos, código propio o modificaciones que deban mantenerse después de actualizar el tema padre y trasladarse fácilmente entre diferentes entornos. Para pequeños ajustes visuales, WordPress ofrece actualmente alternativas mucho más sencillas.

Esta guía explica qué es un tema hijo, cómo funciona junto a los temas modernos de bloques, cómo se crea y en qué situaciones sigue mereciendo la pena utilizarlo.

Puntos clave

• Los temas hijo siguen siendo útiles en 2026 cuando se necesitan personalizaciones PHP, plantillas nuevas o modificadas, cambios importantes de CSS u otras modificaciones basadas en archivos que deban mantenerse tras actualizar el tema padre.
• Un tema hijo básico necesita su propia carpeta y un archivo style.css; normalmente también se añade functions.php para incorporar PHP personalizado o cargar recursos.
• Los pequeños cambios visuales pueden realizarse generalmente desde el Editor del sitio o mediante CSS personalizado, mientras que las funcionalidades independientes del diseño suelen estar mejor ubicadas en un plugin.
• Un tema hijo proporciona un espacio portable y compatible con sistemas de control de versiones para almacenar plantillas, CSS, PHP, configuraciones de theme.json, patrones y otras personalizaciones.

¿Qué es un tema hijo de WordPress en 2026?

Un tema hijo es un tema de WordPress que hereda el diseño y las funcionalidades de otro tema, denominado tema padre. En lugar de sustituirlo, se apoya en esa base y permite ampliar o modificar únicamente los elementos que requieren personalización.

Este concepto fundamental no ha cambiado con la aparición de los temas de bloques. Un tema hijo puede utilizarse tanto con temas tradicionales basados en PHP como con temas modernos de bloques, como Twenty Twenty-Four. Lo que sí ha cambiado es el tipo de archivos con los que se trabaja habitualmente. En los temas clásicos predominan las plantillas PHP y el CSS, mientras que en los temas de bloques adquieren mayor protagonismo theme.json, las plantillas HTML, las partes de plantilla y los patrones.

Es importante tener en cuenta que un tema hijo nunca es completamente independiente. El tema padre debe permanecer instalado porque WordPress seguirá utilizando sus plantillas, estilos, funcionalidades y otros recursos siempre que el tema hijo no proporcione una alternativa.

Esta es también una diferencia importante respecto a los cambios realizados desde el Editor del sitio. Los Estilos globales y muchas personalizaciones hechas desde el editor se almacenan en la base de datos de WordPress. Las modificaciones de un tema hijo, en cambio, se guardan en archivos. Esto facilita su control mediante Git, su traslado entre entornos, su reutilización en otros sitios y su integración en un flujo de desarrollo más estructurado.

Por tanto, no es necesario reproducir el tema padre completo dentro del hijo. Un tema hijo bien planteado contiene únicamente los archivos y configuraciones que realmente necesitan ser diferentes.

Tema padre y tema hijo: cómo funcionan juntos

Cualquier tema normal de WordPress que no haya sido declarado como tema hijo puede actuar, en la práctica, como tema padre. Puede tratarse de un tema tradicional basado en plantillas PHP o de un tema de bloques moderno construido alrededor de theme.json; la relación entre padre e hijo sigue el mismo principio general.

El tema padre aporta la base del sitio: sus plantillas, estilos, patrones, configuraciones y funcionalidades siguen estando disponibles. El tema hijo añade elementos nuevos o sustituye determinados componentes cuando es necesario. Si WordPress encuentra en el tema hijo una plantilla o personalización aplicable, puede utilizar esa versión. Cuando no existe, recurre automáticamente a la correspondiente del tema padre.

Esta herencia selectiva es precisamente lo que hace útiles a los temas hijo. No es necesario duplicar todas las plantillas por el simple hecho de querer modificar una de ellas.

Una forma sencilla de visualizarlo es pensar en el tema padre como el chasis y el motor de un coche. El tema hijo equivaldría a la pintura personalizada, determinados cambios en la carrocería o un sistema electrónico mejorado. La estructura y el funcionamiento esenciales permanecen intactos mientras se modifican únicamente los elementos que necesitan diferenciarse.

La funcionalidad PHP tampoco funciona simplemente mediante sustitución de archivos. El código del tema padre y el del tema hijo pueden complementarse, lo que permite añadir hooks, filtros, recursos y otros comportamientos sin tener que reescribir la lógica existente.

Además, el tema padre puede seguir recibiendo actualizaciones. Los parches de seguridad, las correcciones de errores y las nuevas funciones pueden instalarse sin sobrescribir directamente los archivos donde se han guardado las personalizaciones.

¿Por qué usar un tema hijo en lugar del Editor del sitio?

El Editor del sitio y los Estilos globales han simplificado enormemente muchas personalizaciones de WordPress. Para modificar la tipografía, los colores, el espaciado o determinados aspectos del diseño, en muchos casos es posible realizar todos los cambios necesarios sin crear un tema hijo.

La diferencia empieza a ser importante cuando entra en juego el mantenimiento.

Los cambios realizados desde el Editor del sitio suelen almacenarse en la base de datos. Esto resulta cómodo para la edición cotidiana, pero puede complicar determinados flujos de desarrollo. Las modificaciones almacenadas en archivos pueden controlarse con Git, revisarse, revertirse, trasladarse entre entornos de pruebas y producción o reutilizarse en distintas instalaciones con mucha más facilidad.

Un tema hijo también cobra importancia cuando la personalización va más allá de los aspectos visuales. El Editor del sitio no sustituye la necesidad de utilizar hooks de PHP, filtros, JavaScript, lógica del lado del servidor u otros cambios de código. En estas situaciones, el tema hijo ofrece un lugar seguro para las funcionalidades vinculadas específicamente al tema sin necesidad de alterar el tema padre.

Esta separación resulta especialmente útil para agencias y profesionales que mantienen varios sitios basados en un mismo tema padre. Plantillas, patrones, CSS y modificaciones estructurales pueden almacenarse juntos en un tema hijo portable en lugar de quedar dispersos entre configuraciones de la base de datos y fragmentos de código independientes.

Por tanto, no se trata de considerar un tema hijo como una alternativa superior al Editor del sitio. Son herramientas destinadas a resolver necesidades diferentes. El editor resulta especialmente práctico para realizar ajustes visuales con rapidez; los temas hijo ofrecen mayores ventajas cuando los cambios necesitan ser duraderos, portables, controlables mediante versiones o basados en código.

Cuándo conviene crear un tema hijo y cuándo no

No todos los sitios de WordPress necesitan un tema hijo. La decisión depende principalmente del nivel de personalización y del tipo de mantenimiento previsto.

Conviene utilizar un tema hijo cuando:

• Se van a añadir hooks, filtros o funciones PHP específicos del tema.
• Es necesario crear nuevas plantillas o modificar plantillas y partes de plantilla existentes.
• Se van a realizar cambios importantes en theme.json, como paletas de colores, tipografías, espaciados u otros ajustes de diseño.
• Se mantiene un sitio a largo plazo y conviene separar claramente las personalizaciones de las actualizaciones del tema padre.
• Se quiere reutilizar un sistema de diseño o determinadas modificaciones estructurales en distintos proyectos basados en el mismo tema padre.

Como regla general, resulta conveniente crear el tema hijo antes de comenzar a realizar modificaciones importantes en archivos. Hacerlo desde el principio evita tener que localizar y extraer posteriormente los cambios realizados directamente sobre el tema padre.

Probablemente no sea necesario un tema hijo cuando:

• Solo se requieren algunos cambios visuales sencillos, como modificar un color o una tipografía.
• Todo puede resolverse cómodamente desde el Editor del sitio, el Personalizador o mediante CSS personalizado.
• La funcionalidad que se desea añadir debería continuar funcionando incluso si se cambia de tema.

Este último punto es especialmente importante. Elementos como los tipos de contenido personalizados o los shortcodes deberían formar parte normalmente de un plugin cuando no están directamente vinculados al diseño. Un tema hijo debe contener personalizaciones relacionadas con el tema, no convertirse en un contenedor para toda la funcionalidad personalizada del sitio.

Cómo crear un tema hijo en WordPress: temas clásicos y temas de bloques

El proceso básico para crear un tema hijo es similar tanto si el tema padre es clásico como si se trata de un tema de bloques. Hay que crear un nuevo directorio, añadir la información que WordPress necesita para identificar el tema padre y, posteriormente, incorporar PHP, plantillas, estilos, theme.json u otros archivos según las necesidades del proyecto.

Con un tema clásico, buena parte del trabajo suele realizarse sobre plantillas PHP y CSS. En un tema de bloques, en cambio, es habitual trabajar mucho más con theme.json y plantillas basadas en HTML.

Siempre que sea posible, resulta recomendable crear y probar el tema hijo en un sitio de staging o en un entorno de desarrollo local en lugar de experimentar directamente sobre una web en producción. Algunos temas populares, como Astra, GeneratePress y Kadence, proporcionan además temas hijo básicos ya preparados. Pueden ahorrar tiempo, aunque crear uno manualmente resulta útil para comprender mejor cómo funciona la relación entre padre e hijo.

Según el informe Metorik Insights de 2026, aproximadamente el 66 % de las tiendas WooCommerce no utilizan temas hijo. Esto no significa que todas ellas necesiten uno, pero sí refleja hasta qué punto se ha normalizado desarrollar sitios sin recurrir automáticamente a esta capa tradicional de personalización.

Paso 1: crear la carpeta del tema hijo

El punto de partida se encuentra en el directorio /wp-content/themes/ de la instalación de WordPress. Es posible acceder mediante FTP, SSH, el administrador de archivos del proveedor de alojamiento o directamente desde un entorno de desarrollo local.

Dentro de ese directorio se crea una nueva carpeta para el tema hijo, preferiblemente con un nombre claro y único. Una denominación en formato kebab-case, como twentytwentyfour-child, resulta fácil de reconocer y es especialmente útil cuando en un mismo servidor se alojan varios temas o proyectos.

En este momento, la carpeta puede estar vacía, pero WordPress todavía no la reconocerá como un tema. La información necesaria para hacerlo se añadirá en el siguiente paso.

También puede incorporarse posteriormente un archivo screenshot.png para que el tema disponga de una imagen identificativa en la pantalla Apariencia → Temas. No es imprescindible para su funcionamiento, pero resulta práctico cuando hay varios temas personalizados instalados.

En cualquier caso, la carpeta definitiva del tema hijo debe encontrarse dentro de /wp-content/themes/, ya que es el directorio donde WordPress busca los temas instalados.

Paso 2: añadir style.css e identificar el tema padre

El archivo style.css sirve para identificar el tema hijo ante WordPress. Su comentario de cabecera indica el nombre del tema y, lo más importante, especifica cuál de los temas instalados debe utilizarse como padre.

El valor fundamental es el campo Template. Debe coincidir exactamente con el nombre de la carpeta del tema padre. Por ejemplo, si Twenty Twenty-Four está instalado dentro del directorio twentytwentyfour, el tema hijo deberá incluir Template: twentytwentyfour. Si el nombre no coincide, WordPress no podrá establecer correctamente la relación entre ambos.

En un tema de bloques, style.css puede contener muy poco CSS real, o incluso ninguno, porque buena parte de la configuración visual puede encontrarse en theme.json. Aun así, sigue desempeñando una función importante en la identificación del tema.

También pueden incluirse otros metadatos, como autor, versión, descripción, licencia, dominio de texto o URI del tema. Estos datos resultan especialmente útiles cuando se mantienen varios proyectos o se controlan distintas versiones de un tema personalizado.

Esta es la información básica que normalmente conviene definir:

La idea esencial es sencilla: el tema hijo necesita su propio archivo style.css y este debe identificar correctamente el tema padre.

Paso 3: añadir functions.php y cargar los estilos

El archivo functions.php es el lugar donde pueden almacenarse las personalizaciones PHP específicas del tema. Permite añadir hooks, filtros, compatibilidad con determinadas funcionalidades, áreas de widgets, recursos personalizados y otros comportamientos sin modificar los archivos PHP del tema padre.

En los temas clásicos, functions.php también se utiliza habitualmente para cargar las hojas de estilo en el orden correcto. Dependiendo de cómo gestione el CSS el tema padre, puede ser necesario cargar primero su hoja de estilo y después la del hijo para que las reglas personalizadas puedan sobrescribir correctamente las originales.

Los temas de bloques suelen requerir menos gestión manual de estilos porque una parte mayor del sistema de diseño está controlada desde theme.json. En estos casos, el archivo de funciones puede mantenerse muy reducido y contener solamente el PHP realmente necesario.

Mantenerlo pequeño y organizado es una buena práctica independientemente del tipo de tema. No conviene copiar el archivo functions.php completo del tema padre dentro del hijo. El objetivo del tema hijo es ampliar la funcionalidad del padre, no duplicarla, y copiar funciones completas puede provocar conflictos o incluso errores fatales.

También resulta recomendable utilizar nombres distintivos para las funciones personalizadas. Un nombre como mychild_enqueue_styles() ofrece más seguridad que una función con un nombre genérico que podría existir ya en el tema padre o en algún plugin.

A medida que crece el proyecto, pueden distribuirse distintos grupos de funciones en archivos independientes y cargarlos desde functions.php. El objetivo no es concentrarlo todo en un único archivo, sino mantener el código del tema hijo ordenado y claramente separado del tema padre.

Paso 4: instalar y activar el tema hijo

Una vez que el tema hijo contiene los archivos necesarios para que WordPress lo reconozca, ya puede instalarse y activarse.

Si se ha creado directamente en el servidor dentro de /wp-content/themes/, debería aparecer en Apariencia → Temas. Otra posibilidad consiste en comprimir la carpeta del tema hijo en un archivo ZIP e instalarlo desde Apariencia → Temas → Añadir nuevo → Subir tema.

El tema padre debe estar instalado. No es necesario activar primero el padre para después ejecutar ambos simultáneamente. Se activa únicamente el tema hijo, que utiliza al padre en segundo plano para todo aquello que necesita heredar.

Inmediatamente después de activarlo, la web debería conservar prácticamente el mismo aspecto que con el tema padre si todavía no se han añadido personalizaciones visibles. Esto convierte la primera activación en una prueba especialmente útil. Si el diseño se rompe de repente, conviene revisar el valor Template de style.css, la carga de las hojas de estilo, posibles errores de PHP y la estructura básica de las carpetas.

Probarlo en staging antes de activarlo en producción sigue siendo la opción más segura. Un tema hijo evita que las actualizaciones del tema padre borren las personalizaciones, pero no protege frente a errores introducidos en el propio código.

Personalizar un tema hijo: CSS, plantillas y otros archivos

Una vez activo el tema hijo, pueden añadirse únicamente los elementos que realmente necesiten diferenciarse del padre.

Para los estilos, el CSS personalizado puede incluirse directamente en style.css o distribuirse en hojas de estilo independientes cargadas mediante el archivo de funciones. En un proyecto pequeño, mantener todo el CSS en un mismo archivo puede ser suficiente. En sitios más complejos, dividirlo según su finalidad suele facilitar el mantenimiento.

Las plantillas siguen el mismo principio de personalización selectiva. Cuando es necesario modificar una plantilla concreta de un tema clásico, se puede copiar el archivo correspondiente —por ejemplo, single.php o archive.php— desde el tema padre hasta la misma ubicación del tema hijo y editar esa copia. En los temas de bloques, el concepto es similar para archivos como templates/single.html.

El tema hijo también puede incorporar plantillas que no existan en el padre. Por ejemplo, si un tipo de contenido personalizado necesita un diseño específico, su plantilla correspondiente puede existir exclusivamente dentro del hijo.

También pueden añadirse archivos auxiliares, recursos JavaScript o código organizado en directorios como /inc/. Funciones como get_theme_file_path() y get_theme_file_uri() ayudan a referenciar correctamente los archivos del tema activo.

Lo que conviene evitar es copiar el directorio completo del tema padre dentro del hijo. Hacerlo equivaldría prácticamente a crear una bifurcación del tema original y eliminaría buena parte de las ventajas de mantenimiento que se buscan con esta arquitectura. Cada plantilla duplicada pasa a convertirse en un archivo que puede quedarse desactualizado respecto al padre.

La estrategia más segura consiste, por tanto, en copiar o crear únicamente aquello que realmente vaya a modificarse.

Las herramientas visuales también pueden convivir con este sistema. Elementor Theme Builder, por ejemplo, puede utilizarse junto con un tema hijo cuando se quiere combinar edición visual mediante arrastrar y soltar con una capa basada en archivos para código y otras personalizaciones persistentes.

Trabajar con temas de bloques, theme.json y patrones

Los temas de bloques han cambiado el contenido habitual de un tema hijo, pero no han hecho que esta técnica quede obsoleta.

Los temas modernos utilizan ampliamente theme.json para definir colores, tipografías, espaciado, comportamiento del diseño y ajustes específicos de los bloques. Un tema hijo puede proporcionar su propio archivo theme.json, modificando o ampliando el sistema de diseño del padre sin necesidad de editarlo directamente.

También puede proporcionar sus propias plantillas, partes de plantilla y patrones mediante directorios como templates/ y parts/. Al igual que ocurre con los temas clásicos, basta con incluir aquellos archivos que necesiten ser diferentes.

Como consecuencia, style.css puede tener mucha menos importancia como hoja de estilos propiamente dicha. Muchas decisiones visuales que antes requerían largos bloques de CSS pueden definirse ahora de forma más estructurada mediante theme.json.

No obstante, hay ciertos detalles que conviene vigilar. Algunas configuraciones pueden sustituir, en lugar de combinarse simplemente con, las del tema padre. Por ejemplo, una paleta de colores definida en el theme.json del hijo puede requerir que se incluyan todos los colores que se quieran conservar, y no únicamente los nuevos. En configuraciones de este tipo conviene consultar la documentación oficial de WordPress sobre la herencia entre temas.

También es importante prestar atención a las versiones del esquema. La versión 3 de Theme JSON se introdujo con WordPress 6.6 e incorporó cambios relacionados, entre otros aspectos, con la tipografía fluida y distintas opciones de diseño. Cuando el tema padre utiliza funciones de versiones recientes, la configuración del tema hijo debe ser compatible con ellas.

Para agencias y equipos de desarrollo, este enfoque basado en archivos ofrece otra ventaja: permite gestionar un sistema de diseño mediante control de versiones y reutilizarlo. En lugar de recrear manualmente paletas, tipografías, plantillas y patrones desde el Editor del sitio en cada instalación, todo ello puede empaquetarse dentro de un tema hijo y aplicarse de manera coherente.

Rendimiento, mantenimiento y errores frecuentes

La propia relación entre tema padre y tema hijo no provoca una penalización significativa de rendimiento. Un tema hijo forma parte de la arquitectura normal de WordPress. Si un sitio que utiliza uno se vuelve lento, la causa probablemente se encuentre en código PHP ineficiente, archivos CSS o JavaScript excesivos, imágenes sin optimizar u otros problemas de implementación.

El mantenimiento es una cuestión mucho más relevante.

Uno de los errores más evidentes consiste en eliminar el tema padre. El tema hijo depende de él, por lo que al borrarlo se rompe esa relación. Ambos deben permanecer instalados aunque únicamente el hijo esté activo.

Otro problema habitual es personalizar en exceso. Si se copian decenas de plantillas del padre al hijo, esas copias no incorporarán automáticamente las mejoras que reciban los correspondientes archivos del padre en futuras actualizaciones. Cuantos más archivos se sobrescriban, mayor será la necesidad de revisar los cambios del tema padre para comprobar si también deben actualizarse las versiones personalizadas.

Esta es otra razón para mantener el tema hijo deliberadamente reducido. Conviene almacenar únicamente las personalizaciones significativas y utilizar un sistema de control de versiones como Git cuando la importancia del proyecto lo justifique. De este modo se conserva un historial de cambios y resulta mucho más sencillo determinar qué ha ocurrido si una actualización provoca algún problema.

Las actualizaciones importantes de WordPress o del tema padre también son un buen momento para revisar el tema hijo. Los cambios en plantillas, APIs del tema o esquemas de theme.json pueden acabar afectando a personalizaciones antiguas.

Una ventaja adicional de esta arquitectura es que facilita el diagnóstico de problemas. Si parece que un error procede del tema hijo, cambiar temporalmente al padre permite comprobar con rapidez si la capa de personalización es la responsable.

El objetivo no consiste únicamente en mantener intactos los archivos del tema padre. Se trata de establecer una frontera clara entre el código de terceros que continúa recibiendo mantenimiento y el trabajo personalizado que pertenece específicamente al sitio.

Reflexiones finales

Los temas hijo no han desaparecido en la era de los bloques. Simplemente ocupan ahora un espacio más definido.

Hace una década era habitual presentar la creación de un tema hijo como el método recomendado para prácticamente cualquier personalización importante de WordPress. En 2026, el Editor del sitio, los Estilos globales, las herramientas de CSS personalizado y las opciones de diseño basadas en bloques pueden resolver una proporción mucho mayor de los cambios habituales sin necesidad de crear archivos adicionales.

Y esto supone una ventaja. Crear un tema hijo únicamente para cambiar el color de un encabezado o ajustar unos cuantos valores de espaciado suele resultar innecesario.

Cuando la personalización pasa a ser estructural o incluye código, las ventajas vuelven a ser mucho más evidentes. La lógica PHP, las plantillas personalizadas, los cambios extensos en theme.json, los patrones reutilizables, JavaScript o las modificaciones destinadas a mantenerse durante años se benefician de disponer de un espacio independiente basado en archivos que no se sobrescriba al actualizar el tema padre.

Para agencias, profesionales independientes y equipos de desarrollo, esta separación convierte además al tema hijo en una herramienta de organización. Permite saber exactamente qué se ha modificado y facilita probar, controlar mediante versiones, migrar y reutilizar esos cambios.

Crear un tema hijo suele requerir poco trabajo. Su verdadero valor aparece después, cuando el tema padre recibe una actualización o cuando las mismas personalizaciones tienen que reproducirse en otro entorno.

Por ello, el enfoque más práctico en 2026 no consiste en elegir entre la edición mediante bloques y los temas hijo como si una tecnología hubiera sustituido a la otra. El Editor del sitio resulta adecuado cuando ofrece una solución sencilla y eficiente. El tema hijo, en cambio, resulta especialmente útil para aquellos cambios que necesitan vivir en archivos, sobrevivir a las actualizaciones o trasladarse de forma fiable entre distintos sitios.

Cuando se prevé que las personalizaciones de un sitio puedan crecer, comenzar con un tema hijo mínimo en un entorno de staging puede simplificar mucho el mantenimiento futuro. Aunque inicialmente solo existan unos pocos cambios, mantenerlos separados del tema padre facilita las actualizaciones posteriores.

Preguntas frecuentes

¿Es necesario utilizar un tema hijo en todos los sitios de WordPress ahora que existe el Editor del sitio?

No. Un blog sencillo, una web corporativa básica o un portfolio pueden funcionar perfectamente utilizando el Editor del sitio, los Estilos globales y una pequeña cantidad de CSS personalizado.

Un tema hijo comienza a resultar más útil cuando el sitio requiere PHP personalizado, plantillas avanzadas, un sistema de diseño reutilizable o una capa de personalización basada en archivos que facilite su mantenimiento a largo plazo. En proyectos con modificaciones amplias de temas de terceros puede resultar conveniente utilizar uno de forma habitual, mientras que los sitios con pequeños cambios visuales pueden no necesitarlo nunca.

¿Se pueden trasladar las personalizaciones existentes a un tema hijo más adelante?

Sí. El CSS personalizado existente puede trasladarse desde el Personalizador o el Editor del sitio hasta la hoja de estilos del tema hijo cuando interesa centralizar esas modificaciones en archivos.

Si se han editado directamente archivos del tema padre, el proceso requiere más cuidado. Las versiones modificadas pueden trasladarse al tema hijo cuando corresponda y después debería restaurarse el tema padre a su estado original. Conviene probar todo el proceso en un entorno de staging antes de aplicarlo en producción para detectar posibles funciones ausentes, diferencias de estilos o problemas con las plantillas.

Crear el tema hijo posteriormente es perfectamente posible, aunque suele ser más sencillo hacerlo antes de comenzar una personalización profunda.

¿Qué ocurre si el tema padre deja de mantenerse o se elimina?

Un tema hijo depende de su tema padre, por lo que eliminar este último de la instalación de WordPress provocará problemas. Conviene mantener copias de seguridad de ambos.

Una situación más complicada se produce cuando el desarrollador original abandona definitivamente el tema padre. El tema hijo puede seguir funcionando durante un tiempo, pero depender indefinidamente de código sin mantenimiento puede terminar generando problemas de seguridad y compatibilidad.

En un sitio que deba mantenerse durante muchos años, puede llegar a ser necesario migrar a otro tema que siga recibiendo actualizaciones o convertir el trabajo existente en un tema independiente. Es una cuestión especialmente importante al seleccionar un tema padre para proyectos de larga duración.

¿Se pueden utilizar varios temas hijo en un mismo sitio?

Es posible instalar varios temas hijo, pero WordPress solo permite tener un tema activo a la vez. Por tanto, no es posible utilizar simultáneamente distintos temas hijo para controlar diferentes partes de una misma web.

Sí pueden crearse temas hijo diferentes para varios sitios que utilicen un mismo tema padre. Una agencia, por ejemplo, puede utilizar la misma base en diversos proyectos y proporcionar a cada sitio su propio tema hijo con identidad visual, plantillas y código personalizado.

En este tipo de entornos, utilizar nombres de carpeta claros y diferenciados resulta especialmente conveniente.

¿Hace falta un tema hijo para añadir unas pocas líneas de CSS personalizado?

Normalmente no. Si únicamente se necesitan unas cuantas reglas CSS, las opciones de CSS adicional o las herramientas de CSS personalizado del Editor del sitio suelen ofrecer una solución más sencilla.

Un tema hijo empieza a tener más sentido cuando esos ajustes aumentan considerablemente, sobre todo si al CSS se suman JavaScript, PHP, modificaciones de plantillas o la necesidad de utilizar control de versiones y trasladar fácilmente las personalizaciones.

En definitiva, no es necesario crear un tema hijo anticipándose a cualquier posible cambio futuro. Lo más razonable es empezar con la herramienta más sencilla que resuelva las necesidades actuales y pasar a un tema hijo cuando el alcance de la personalización justifique una estructura más organizada.