OpenAI Codex: qué es y cómo encaja en un flujo de trabajo con código, Git y revisión

Pedir a una IA que escriba una función es relativamente fácil. El problema empieza cuando esa función tiene que convivir con el resto de un proyecto: archivos relacionados, dependencias, convenciones, pruebas y cambios que no quieres romper.

Ahí es donde OpenAI Codex cambia el tipo de trabajo que puedes delegar.

OpenAI Codex es un agente de programación de OpenAI capaz de trabajar con el contexto de un proyecto, inspeccionar archivos, modificar código y utilizar herramientas para ejecutar y comprobar tareas. Dependiendo de cómo lo uses, puedes trabajar con Codex desde entornos como el terminal, el IDE o la nube.

La diferencia importante no es simplemente que pueda generar más código.

Es que puedes pasar de pedir una respuesta aislada a encargar una tarea sobre un proyecto.

Y eso cambia también tu responsabilidad.

Si un agente puede intervenir en varios archivos, ejecutar comandos y preparar cambios, ya no basta con preguntarte si el código que genera «parece correcto». Necesitas saber qué debe hacer, qué puede tocar, qué no debe modificar, cómo vas a revisar el resultado y cómo volverás atrás si el cambio no funciona.

Una forma práctica de entender el flujo es esta:

TAREA → CONTEXTO → LÍMITES → CAMBIO → DIFF → PRUEBA → DECISIÓN → REVERSIÓN

Vamos a recorrerlo porque ahí está la diferencia entre utilizar Codex como otro generador de código y utilizarlo dentro de un sistema de trabajo controlado.

Este enfoque forma parte de la manera en que trabajo la IA, el desarrollo web y el aprendizaje aplicado en Ricardo Lozano.

Qué es OpenAI Codex

Codex es un agente de programación orientado a realizar tareas de desarrollo de software.

La documentación actual de OpenAI describe Codex trabajando sobre código y proyectos: puede inspeccionar archivos, modificarlos y ejecutar comandos. El producto dispone además de distintas superficies de trabajo, por lo que conviene no identificar «Codex» exclusivamente con su interfaz de terminal.

Puedes comprobar las capacidades vigentes en la documentación oficial de Codex CLI.

Para entender la diferencia práctica, imagina que tienes un formulario que acepta un dato que debería rechazar.

En un chat convencional podrías copiar parte del código y preguntar:

«¿Por qué esta validación no funciona?»

La IA analiza principalmente el contexto que has introducido y devuelve una explicación o una propuesta de código.

Con un agente trabajando sobre el proyecto puedes plantear una tarea diferente:

«Localiza dónde se valida este formulario, identifica por qué acepta este valor, prepara el cambio mínimo, ejecuta las pruebas relacionadas y explícame qué has modificado».

Ya no estás solicitando solamente una respuesta.

Estás definiendo una tarea dentro de un sistema.

El agente puede necesitar localizar archivos, entender cómo se relacionan, modificar una parte del proyecto y utilizar las herramientas disponibles para comprobar el resultado.

Ese es el primer cambio que merece la pena retener:

la unidad de trabajo deja de ser necesariamente el fragmento de código y puede pasar a ser la tarea.

Pero delegar una tarea más completa no significa delegar también la decisión de aceptar el resultado.

Qué cambia cuando la IA puede trabajar con un proyecto de código

Volvamos al formulario.

Sabemos qué queremos conseguir: impedir que un valor incorrecto supere la validación.

Eso define el objetivo, pero todavía faltan preguntas importantes.

¿Dónde está la lógica que provoca el problema?

¿Hay pruebas existentes?

¿Puede modificarse cualquier archivo?

¿Queremos una corrección localizada o permitimos una refactorización?

¿Hay dependencias que no deberían actualizarse?

¿Cómo sabremos que la solución funciona?

Cuanto mayor es la autonomía del agente, más importantes se vuelven estas preguntas.

Por eso el cambio interesante de Codex no consiste en sustituir un prompt corto por uno enorme. Consiste en preparar mejor la tarea.

OpenAI recomienda proporcionar al agente información como el objetivo, el contexto, las restricciones y una definición clara de qué significa terminar correctamente. Puedes ampliar este enfoque en sus prácticas recomendadas para trabajar con Codex.

Una petición como:

«Arregla el formulario»

deja muchas decisiones abiertas.

Una instrucción como:

«Localiza por qué el formulario acepta este valor. Limita el cambio a la validación y sus pruebas relacionadas. No actualices dependencias. Ejecuta las pruebas pertinentes y explícame el diff antes de considerar terminada la tarea.»

define mucho mejor el terreno.

No porque exista un prompt mágico, sino porque has hecho explícitas cuatro cosas:

qué quieres conseguir;

hasta dónde puede llegar el cambio;

qué restricciones debe respetar;

qué evidencia necesitas para aceptar el resultado.

Ese es un criterio que puedes reutilizar aunque cambien los modelos o la interfaz de Codex.

Repositorio, instrucciones y permisos

Un proyecto contiene más información de la que aparece en su código.

También tiene convenciones, arquitectura, dependencias, comandos de desarrollo, pruebas y decisiones acumuladas con el tiempo.

Parte de ese contexto puede resultar evidente para quien lleva meses trabajando en el repositorio y ser completamente desconocido para un agente que acaba de recibir una tarea.

Por eso, antes de delegar, conviene poder responder a cinco preguntas:

¿Qué quiero cambiar?

¿Qué necesita conocer el agente para entender el problema?

¿Qué puede tocar?

¿Qué debe dejar intacto?

¿Cómo voy a comprobar que ha terminado correctamente?

Estas preguntas convierten el contexto en una herramienta de control.

OpenAI contempla mecanismos como AGENTS.md para proporcionar instrucciones persistentes dentro de los repositorios. Codex también dispone de controles relacionados con los permisos y las acciones que puede realizar.

No necesitas llenar el proyecto de instrucciones por precaución.

Necesitas proporcionar el contexto que cambie decisiones.

Si una convención de arquitectura importa, indícala.

Si determinados archivos no deben modificarse, delimítalos.

Si existe un comando concreto para validar la tarea, inclúyelo.

Si una acción puede tener consecuencias importantes, no la conviertas en una decisión implícita del agente.

La autonomía útil no consiste en eliminar los controles. Consiste en dejar que el agente avance dentro de un terreno suficientemente bien definido.

Y cuando empieza a modificar ese terreno, aparece la siguiente pieza del sistema: saber exactamente qué ha cambiado.

Git y revisión de cambios

Codex y Git resuelven problemas distintos.

Codex puede ayudarte a producir cambios en el proyecto.

Git permite registrar estados, comparar modificaciones y mantener trazabilidad sobre la evolución del código.

Volvamos al formulario.

El agente ha localizado la validación y ha preparado una corrección.

Ahora importa menos que su explicación suene convincente y más poder responder:

¿qué archivos ha modificado realmente?

El diff te permite comprobarlo.

Quizá esperabas un cambio en la función de validación y su prueba correspondiente. Si encuentras además modificaciones en configuración, dependencias y componentes no relacionados, tienes una señal que merece revisión.

No significa automáticamente que esos cambios estén mal.

Significa que el alcance real ya no coincide con el alcance que esperabas y necesitas entender por qué.

Ese detalle es importante porque una tarea aparentemente pequeña puede expandirse mientras el agente intenta resolverla.

La revisión debería preguntarse, como mínimo:

• qué archivos se han modificado;
• qué se ha añadido y eliminado;
• si el cambio permanece dentro del alcance acordado;
• si aparecen modificaciones que el agente no necesita para resolver la tarea;
• y si entiendes suficientemente el resultado como para continuar con la validación.

Así, Git no se convierte en un «botón de seguridad».

Se convierte en una capa de trazabilidad.

El flujo hasta aquí ya empieza a ser visible:

TAREA → CONTEXTO → LÍMITES → CAMBIO → DIFF

Pero todavía falta una parte crítica.

Que el cambio sea comprensible no demuestra que funcione.

Pruebas, QA y rollback

Nuestro formulario ya tiene una modificación concreta y un diff revisable.

Ahora toca intentar demostrar que resuelve el problema.

Primero puedes comprobar el caso que originó la tarea: el valor incorrecto debe dejar de ser aceptado.

Después necesitas mirar alrededor.

¿Los valores válidos siguen funcionando?

¿Pasan las pruebas relacionadas?

¿Se ha producido una regresión?

¿La solución depende de una condición que no existe en otro entorno?

¿El cambio puede afectar a otra parte del proyecto?

OpenAI explica que Codex puede ejecutar código y pruebas dentro de sus flujos de trabajo. También mantiene controles orientados a limitar las acciones que los agentes pueden realizar. Puedes consultar el enfoque de seguridad y controles de Codex para entender por qué permisos y supervisión forman parte del problema.

Aquí conviene mantener separados tres conceptos.

Prueba responde a una pregunta como: «¿se comporta el sistema como esperamos en este escenario?».

Revisión responde a otra: «¿entiendo y acepto el cambio que se ha realizado?».

Rollback responde a una tercera: «¿qué hago si necesito deshacerlo?».

No son intercambiables.

Tampoco debes tratar Git como si fuese automáticamente un backup completo de todo el proyecto.

Git puede ayudarte a recuperar estados del código versionado. Pero una aplicación puede depender también de base de datos, archivos generados, infraestructura, configuración externa o servicios que necesiten su propia estrategia de copia y reversión.

Por eso el nivel de control debe crecer con el riesgo.

Modificar una función en una rama de desarrollo no plantea el mismo escenario que ejecutar un cambio sobre un sistema en producción.

La pregunta útil no es:

«¿Codex puede hacerlo?»

La pregunta es:

«¿Qué tendría que comprobar para aceptar con criterio que lo ha hecho bien?»

Ese pequeño cambio de pregunta mejora mucho el uso de cualquier agente de programación.

Un método para trabajar con Codex sin delegar el criterio

Ya podemos completar el recorrido:

TAREA → CONTEXTO → LÍMITES → CAMBIO → DIFF → PRUEBA → DECISIÓN → REVERSIÓN

No es una configuración oficial de Codex ni una secuencia obligatoria del producto.

Es un modelo de trabajo para no confundir capacidad de ejecución con calidad del resultado.

TAREA

Define el resultado que buscas.

No «mejora este código», sino qué problema necesitas resolver.

CONTEXTO

Proporciona la información que pueda cambiar las decisiones del agente: arquitectura, convenciones, archivos relevantes, comandos o requisitos.

LÍMITES

Decide qué puede modificar, qué debe respetar y qué acciones necesitan mayor control.

CAMBIO

Deja que el agente realice la tarea dentro de ese marco.

DIFF

Comprueba qué ha cambiado realmente, no solo cómo lo resume el agente.

PRUEBA

Busca evidencia de que el comportamiento esperado funciona y de que no has roto lo que ya funcionaba.

DECISIÓN

Aceptar, corregir, pedir otra iteración o descartar siguen siendo decisiones tuyas.

REVERSIÓN

Antes de llevar un cambio de riesgo a un entorno importante, necesitas saber cómo recuperar un estado válido.

Este modelo también ayuda a detectar cuándo estás pidiendo demasiado de una sola vez.

Si no puedes describir con claridad qué esperas comprobar al final, quizá la tarea todavía sea demasiado grande o ambigua.

Y ahí aparece una de las paradojas interesantes de los agentes de código:

cuanta más autonomía quieres delegar, más importante resulta diseñar bien el sistema de control.

Cuándo pasar de Codex general a un flujo específico

Entender Codex no significa que necesites aprender inmediatamente todas sus interfaces, comandos y configuraciones.

El siguiente paso depende del problema que quieras resolver.

Si necesitas trabajar directamente desde el terminal, preparar un repositorio y profundizar en la ejecución técnica, continúa con la guía de Codex CLI.

Esa pieza entra en una intención diferente: cómo preparar y utilizar la herramienta dentro de un flujo con código y Git.

Si lo que quieres es aplicar Codex a una web WordPress, el contexto vuelve a cambiar.

En WordPress necesitas distinguir entre core, tema, tema hijo, plugins, snippets, CSS, PHP, base de datos, hosting y otras capas. También cobran especial importancia staging, backups y rollback cuando un cambio puede afectar a una web en producción.

Ese recorrido continúa en OpenAI Codex aplicado a WordPress.

La separación es intencionada.

Este artículo responde a qué es Codex y qué cambia en la forma de trabajar con código.

Las otras guías profundizan en ejecuciones concretas sin convertir esta introducción en una enciclopedia.

Qué deberías llevarte antes de empezar

Volvamos al formulario del principio.

Empezamos queriendo corregir una validación.

Podríamos haber pedido código, copiarlo y comprobar si aparentemente funcionaba.

En cambio, hemos recorrido otra secuencia:

definimos la tarea;

dimos contexto;

limitamos el alcance;

dejamos que el agente actuara;

revisamos el diff;

probamos el comportamiento;

decidimos si aceptar el cambio;

y conservamos una vía para volver atrás.

Eso resume bastante bien qué cambia con Codex.

No se trata simplemente de generar código más rápido. Se trata de poder delegar una parte mayor del trabajo sin delegar también el criterio con el que aceptas el resultado.

Antes de encargar una tarea real, intenta responder estas cinco preguntas:

1. ¿Qué quiero conseguir exactamente?
2. ¿Qué contexto necesita Codex para decidir bien?
3. ¿Qué puede tocar y qué debe dejar intacto?
4. ¿Qué evidencia necesito para aceptar el cambio?
5. ¿Cómo vuelvo atrás si descubro un problema?

Si alguna respuesta es «no lo sé», has encontrado el siguiente punto que debes preparar.

Y eso suele ser más útil que escribir un prompt más largo.

Si quieres seguir aprendiendo con este enfoque práctico, en el blog encontrarás nuevas guías sobre IA, WordPress, SEO y herramientas aplicadas a proyectos reales.

Aplicarlo a tu propio proyecto

Puedes practicar el método con una tarea pequeña y reversible: un bug localizado, una prueba que falta o una modificación cuyo alcance puedas revisar con facilidad.

El objetivo de la primera práctica no debería ser comprobar cuánto puede hacer Codex sin supervisión.

Debería ser aprender a construir un flujo en el que puedas distinguir con claridad qué pediste, qué hizo, qué comprobaste y por qué aceptaste el resultado.

Si quieres aplicarlo sobre tu propio proyecto en una clase online 1:1, podemos trabajar precisamente así: tú ejecutas sobre tu caso y revisamos juntos cómo definir la tarea, preparar el contexto, limitar el riesgo y validar los cambios.

Dudas habituales sobre OpenAI Codex

GeneratePress y GenerateBlocks: qué hace cada uno y cómo usarlos juntos en WordPress

GeneratePress y GenerateBlocks suelen aparecer juntos en WordPress, pero cumplen funciones diferentes.

GeneratePress es el tema. GenerateBlocks aporta bloques y herramientas de construcción dentro del editor. El primero establece buena parte de la base general del sitio; el segundo te permite construir estructuras, layouts y componentes dentro del contenido.

La diferencia parece sencilla hasta que empiezas a diseñar. Puedes definir un color global, repetirlo manualmente en varios bloques, corregir después una tarjeta con CSS y terminar con distintos sitios controlando prácticamente lo mismo.

La web puede seguir viéndose bien. El coste aparece cuando quieres cambiarla.

Por eso hay una pregunta que conviene hacer antes de abrir otro panel:

¿qué capa debería ser responsable de esta decisión?

Esa pregunta ayuda a utilizar GeneratePress y GenerateBlocks como partes de una misma arquitectura sin convertir la web en una acumulación de ajustes difíciles de rastrear.

Qué es GeneratePress y qué papel cumple en WordPress

GeneratePress es un tema de WordPress. Su papel está en la base del sitio y en aquellas decisiones que tiene sentido compartir de forma general.

Un ejemplo claro son los colores. GeneratePress dispone actualmente de Global Colors reutilizables que puedes aplicar a diferentes elementos. La ventaja práctica es poder modificar una decisión compartida sin perseguir valores aislados página por página. La documentación oficial de GeneratePress sobre Global Colors describe ese funcionamiento.

Piensa en un color de marca utilizado en enlaces, botones y detalles de interfaz. Si pertenece a la identidad general, escribir su hexadecimal manualmente cada vez crea varias copias de la misma regla.

Con la tipografía ocurre algo parecido. Si cuerpo, encabezados o enlaces comparten una base visual en toda la web, conviene decidir dónde se mantiene esa base antes de reconstruirla página por página.

Eso deja sitio para las excepciones. Una sección concreta puede necesitar otra composición y un componente puede requerir una variante propia.

La frontera útil es sencilla:

lo que debe cambiar junto conviene mantenerlo junto.

Así evitas tanto cargar el tema con decisiones demasiado específicas como recrear reglas globales en cada bloque.

Qué es GenerateBlocks y qué problema resuelve

GenerateBlocks es un plugin que amplía el editor de bloques de WordPress con herramientas orientadas a estructura, contenido y diseño.

Está pensado para trabajar estrechamente con GeneratePress, pero no depende técnicamente de ese tema: la ficha oficial del plugin confirma que funciona también con otros temas de WordPress. La ficha oficial de GenerateBlocks en WordPress.org recoge expresamente esa compatibilidad.

En la documentación actual, Container es el bloque principal para agrupar elementos y construir layouts. Grid es una variante de Container configurada para trabajar con CSS Grid.

Imagina una sección de servicios con fondo, ancho interior, título, texto, tres tarjetas y un CTA. El tema puede aportar parte de la base general, pero la composición concreta de esa sección pertenece al contenido que estás construyendo.

Una forma rápida de recordarlo es:

GeneratePress establece la base; GenerateBlocks compone.

Algunas propiedades pueden modificarse desde más de un lugar. Por eso la pregunta importante no es únicamente dónde puedes tocar algo, sino desde dónde quieres editarlo después.

GenerateBlocks dispone además de un panel de estilos con controles para layout, spacing, sizing, tipografía, fondos y responsive. Esa capacidad facilita el diseño, pero también permite acumular estilos locales si cada bloque se resuelve como un caso independiente.

Cuando preparo una sección, primero separo estructura, elementos que se repiten y excepciones. Solo después entro en el detalle visual. Ese orden reduce correcciones posteriores y deja más claro qué debería cambiar junto.

GeneratePress vs GenerateBlocks: qué gobierna cada uno

No necesitas aprender una frontera rígida. Necesitas saber dónde conviene empezar a resolver cada necesidad.

GenerateBlocks separa además los Settings, relacionados con características del bloque y su estructura HTML, de los Styles, donde se aplican propiedades CSS. Esa separación técnica resulta útil para no mezclar estructura y acabado sin necesidad.

Cuando dudes, hazte esta pregunta:

¿desde dónde quiero cambiar esto dentro de seis meses?

Si veinte botones deberían responder al mismo criterio visual, veinte configuraciones independientes convierten una modificación sencilla en veinte tareas.

Si uno de esos botones cumple otra función, su variante puede estar perfectamente justificada.

Cómo usarlos juntos sin duplicar estilos ni soluciones

Una forma práctica de ordenar las decisiones es:

global → componente → excepción → código

No son cuatro pasos obligatorios. Sirven para decidir qué alcance tiene lo que estás cambiando.

Antes de tocar un ajuste, comprueba:

1. ¿Qué alcance tiene? ¿Afecta a todo el sitio, a un componente o solo a esta instancia?
2. ¿Se repite? Si aparece varias veces, quizá no deberías mantener cada copia por separado.
3. ¿Dónde debería cambiarse después? Busca un único lugar lógico para editarlo.
4. ¿Es una excepción real? Que algo pueda ser distinto no significa que necesite serlo.
5. ¿Hace falta CSS o código? Añádelo cuando las capas anteriores no resuelvan bien la necesidad.

Ese pequeño recorrido evita empezar por la herramienta antes de saber qué problema estás resolviendo.

Contenedores, grid y espaciado

Conviene resolver la estructura antes que el acabado.

GenerateBlocks permite trabajar layouts con flex, grid, alineaciones, distribución y gaps. Su variante Grid utiliza CSS Grid para construir cuadrículas.

El problema aparece cuando cada sección inventa sus propias medidas.

Si una web utiliza separaciones verticales de 72, 69, 75, 66 y 81 píxeles sin una razón visual, elegir cuál es el número «correcto» no arregla nada. Falta una lógica común.

Resulta más útil distinguir entre:

• separación entre secciones;
• padding interno;
• separación entre elementos;
• gap entre columnas o tarjetas.

Los valores concretos dependerán del diseño. Lo importante es saber qué función cumple cada espacio para poder modificarlo después con criterio.

Responsive debería resolverse al mismo tiempo. El panel de estilos actual de GenerateBlocks incorpora controles para aplicar estilos según diferentes tamaños de pantalla.

En lugar de diseñar tres webs independientes, decide qué necesita transformarse: una cuadrícula pierde columnas, varios elementos se apilan, un padding disminuye o la escala tipográfica cambia.

Así responsive forma parte de la construcción desde el principio y no de una ronda de parches al final.

Tipografía, colores y componentes

Las duplicidades suelen aparecer poco a poco.

Imagina una tarjeta con fondo, radio, borde, padding, H3 y enlace. La duplicas varias veces, modificas dos copias y unas semanas después construyes otra casi idéntica en otra página.

Entonces merece la pena preguntar:

¿tengo varias tarjetas o un componente con variantes?

GenerateBlocks Pro dispone actualmente de Global Styles, una función Pro para definir estilos reutilizables y aplicarlos a diferentes GenerateBlocks. La documentación actual de Global Styles confirma tanto su carácter Pro como su funcionamiento reutilizable.

Eso no implica que necesites Pro para aplicar este criterio ni que todo deba convertirse en un Global Style.

Antes de crear otra variante, comprueba:

¿debería cambiar en todas las instancias o únicamente aquí?

Si todas deben cambiar juntas, probablemente existe una regla compartida. Si este caso cumple una función distinta, la excepción es razonable.

Ese criterio evita dos extremos: convertir cualquier detalle en regla global o repetir localmente lo que debería mantenerse desde un solo sitio.

Cuándo añadir CSS personalizado

CSS personalizado puede ser la solución correcta. El problema es utilizarlo antes de saber qué estás corrigiendo.

Antes de escribir una regla, reviso:

1. de dónde viene el estilo actual;
2. dónde se repite;
3. dónde debería mantenerse;
4. si este caso es realmente una excepción;
5. si CSS resuelve algo que las capas anteriores no pueden resolver limpiamente.

Ese diagnóstico cobra especial importancia cuando la reacción inmediata es aumentar especificidad o añadir !important. Si dos reglas compiten, una tercera puede ocultar el conflicto sin resolver su origen.

GenerateBlocks Pro dispone actualmente de un CSS Editor integrado para bloques y Global Styles. La función está documentada para GenerateBlocks Pro 2.6.

Pero la existencia del editor no cambia el criterio:

primero diagnostica; después escribe CSS.

Si todas tus tarjetas necesitan el mismo padding, revisaría primero si debería formar parte de una regla reutilizable. Si buscas un comportamiento específico que los controles disponibles no resuelven con claridad, una clase estable y una regla CSS localizada pueden ser más fáciles de mantener.

El código debería cerrar una necesidad concreta, no esconder una arquitectura confusa.

Cuándo no necesitas GenerateBlocks

Usar GeneratePress no te obliga a instalar GenerateBlocks.

Si el editor de WordPress y tu tema ya resuelven con claridad la estructura que necesitas, añadir otra herramienta puede aportar poco.

También puede ocurrir que una web ya utilice otro sistema de construcción coherente. Sustituirlo porque has encontrado un tutorial diferente puede añadir más trabajo que el que elimina.

Antes de incorporar GenerateBlocks preguntaría:

• ¿necesito estructuras que ahora no puedo construir con claridad?
• ¿voy a reutilizar componentes?
• ¿necesito más control sobre layout y responsive?
• ¿estoy sustituyendo una herramienta o colocando otra encima?

Menos plugins tampoco significa automáticamente una web mejor.

Dos herramientas con funciones distintas pueden formar un stack perfectamente razonable. La dificultad aparece cuando varias intentan controlar lo mismo y ya no sabes dónde editar una decisión.

Tampoco atribuiría una mejora de rendimiento simplemente a instalar GeneratePress o GenerateBlocks. El resultado depende de la implementación completa: imágenes, fuentes, plugins, servidor, caché, scripts, CSS, contenido y configuración, entre otros factores.

Elegir las herramientas importa. Cómo las utilizas importa todavía más.

Cómo conectar un diseño de Figma con esta estructura

Un diseño de Figma no debería convertirse en una lista de píxeles que copias pantalla por pantalla a WordPress.

Primero hay que traducir el sistema visual.

Cuando paso de Figma a WordPress, empiezo por estas preguntas:

• ¿qué se repite?
• ¿qué es global?
• ¿qué componente existe aquí?
• ¿qué pertenece a la estructura de la página?
• ¿qué cambia en responsive?
• ¿qué es realmente excepcional?

Una paleta repetida, una jerarquía tipográfica o un ancho común suelen apuntar a decisiones generales.

Una tarjeta presente en varias páginas es un componente.

Una hero de dos columnas plantea una estructura que puede traducirse a contenedores y grid.

Un detalle único puede quedarse como excepción si responde a una función concreta.

Después asignas cada parte a la capa adecuada y construyes. CSS queda para aquello que necesita una solución adicional de verdad.

Esta forma de trabajar evita perseguir la apariencia final antes de tener resuelta la estructura y hace que el diseño siga siendo comprensible cuando llegue el momento de editarlo.

Si quieres seguir profundizando en WordPress, diseño y construcción web, puedes continuar por las guías del blog.

Si quieres aplicar este criterio a una web real, podemos trabajarlo en una clase online 1:1. Tú compartes pantalla y haces los cambios sobre tu proyecto; yo te ayudo a decidir qué debe vivir en el tema, qué conviene construir con bloques y cuándo CSS o código aportan una solución más clara. Revisamos y corregimos juntos para que entiendas el criterio y puedas mantener la web después con más autonomía.

4. INTERLINKING OPERATIVO

La URL registrada para ART-WP-006 ha sido comprobada en esta ejecución y actualmente responde 404, por lo que no se activa. ART-SEO-006 sigue sin una URL canónica confirmada en las fuentes disponibles.

Resultado: el artículo se publica sin ambos enlaces. No existe ninguna URL interna dudosa o rota dentro del cuerpo.

Qué significa SEO: cómo funciona el posicionamiento en buscadores y qué trabajar primero

Puedes instalar Rank Math, poner una keyword en el H1, escribir una metadescripción y conseguir que varias comprobaciones aparezcan en verde.

Y aun así estar empezando por el sitio equivocado.

Porque antes de tocar esos elementos hay una pregunta más importante: ¿qué búsqueda quieres resolver y qué página de tu web debería hacerlo?

SEO son las siglas de Search Engine Optimization, optimización para motores de búsqueda. En la práctica, es el trabajo de ayudar a que los buscadores puedan descubrir y comprender tus páginas y de hacer que esas páginas respondan de forma útil a búsquedas relevantes. Incluye decisiones sobre intención, arquitectura, contenido, técnica y medición.

La guía oficial de iniciación al SEO de Google Search Central explica el SEO como un trabajo orientado a facilitar que los buscadores entiendan el contenido y que las personas puedan encontrarlo y decidir si les resulta útil. También deja claro que no existe una técnica que garantice automáticamente una primera posición.

Por eso prefiero pensar en SEO como un sistema de decisiones, no como una colección de ajustes.

El SEO no empieza en el plugin. Empieza cuando entiendes qué busca una persona y qué URL debería responder.

Eso no convierte la parte técnica en secundaria. Significa que un plugin o una herramienta no puede decidir por ti cuál es el problema SEO que necesitas resolver.

Qué significa SEO

SEO significa Search Engine Optimization, que suele traducirse como optimización para motores de búsqueda.

La traducción explica las siglas, pero se queda corta si quieres entender qué haces realmente cuando trabajas SEO.

Optimizar una web no consiste simplemente en repetir una palabra clave o cambiar un título. Significa mejorar las condiciones para que una página pueda ser descubierta, interpretada y considerada una respuesta pertinente para determinadas búsquedas.

Imagina una web que ofrece clases online de SEO. Podría tener una página de servicio, artículos educativos, una página sobre el método de trabajo y distintos recursos.

Si alguien busca:

qué significa seo

su necesidad no es necesariamente contratar una clase en ese instante. Probablemente quiere comprender el concepto.

En cambio, una búsqueda relacionada con contratar formación personalizada puede necesitar una página con otra función, otro contenido y otro siguiente paso.

Las dos búsquedas hablan de SEO. Eso no significa que deban recibir la misma respuesta.

Ahí aparece una de las primeras decisiones importantes: una keyword es una pista sobre una necesidad, no una orden para meter una frase dentro de una página.

Cuando reviso una web, prefiero aclarar esa relación antes de tocar title, H1 o metadescripción. Un elemento on-page puede estar bien optimizado y seguir trabajando sobre una página cuya función no corresponde a la búsqueda.

También conviene separar dos expresiones que suelen utilizarse casi como sinónimas. Posicionamiento web describe habitualmente el objetivo de ganar visibilidad en buscadores; SEO abarca el trabajo y las decisiones que contribuyen a conseguir esa visibilidad.

Para qué sirve el SEO en una web real

El SEO sirve para mejorar la capacidad de una web de aparecer y resultar útil cuando alguien realiza búsquedas relacionadas con lo que esa web explica, ofrece o resuelve.

Pero visibilidad por sí sola no es un objetivo suficientemente preciso.

Imagina que consigues muchas impresiones para una consulta que apenas tiene relación con tu servicio, o que atraes visitas a un artículo desde el que el lector no puede continuar hacia ninguna información relevante.

Has conseguido presencia. No necesariamente has construido una buena pieza SEO.

En una web real interesa conectar:

• una demanda o necesidad;
• una intención suficientemente comprendida;
• una página con una función concreta;
• contenido capaz de resolver esa necesidad;
• una web que permita descubrir y procesar esa página;
• y datos posteriores para comprobar qué está ocurriendo.

Por ejemplo, si una empresa quiere captar solicitudes para un servicio, crear diez artículos porque una herramienta muestra volumen puede ser menos importante que descubrir que su página principal de servicio no responde bien a la necesidad comercial que realmente le interesa.

También puede ocurrir lo contrario: la página comercial está clara, pero el usuario todavía necesita aprender, comparar o resolver dudas antes de plantearse contactar.

SEO no consiste en llevar todas las búsquedas a la página que más te interesa vender. Consiste en construir la respuesta adecuada para cada función que realmente merece existir.

Por eso una buena decisión SEO puede ser crear una página, mejorar una existente, unir contenidos que se pisan o, sencillamente, no crear otra URL.

Cómo funciona la lógica SEO: búsqueda → intención → URL → contenido → medición

Una forma sencilla de ordenar mentalmente el trabajo SEO es esta:

búsqueda → intención → URL → contenido → medición

No pretende describir todo lo que ocurre dentro de Google. Es un modelo de trabajo para entender cómo se relacionan las decisiones.

Búsqueda

Empiezas observando qué intenta encontrar la persona. Una query aporta lenguaje y contexto, pero no explica por sí sola toda la necesidad.

Varias expresiones diferentes pueden corresponder a una misma intención y una frase parecida puede esconder necesidades distintas.

Intención

Después intentas entender qué quiere conseguir quien busca.

¿Aprender? ¿Comparar? ¿Resolver una duda? ¿Encontrar una herramienta? ¿Contratar? ¿Llegar a una página concreta?

No necesitas encerrar cada búsqueda en una etiqueta perfecta. Necesitas comprenderla lo suficiente para decidir qué respuesta tendría sentido.

URL

Entonces aparece una decisión de arquitectura:

¿qué página debería responder?

Quizá ya existe. Quizá falta. Quizá dos URLs están intentando resolver prácticamente lo mismo. O quizá la duda puede quedar cubierta dentro de una página que ya tienes.

Crear primero y ordenar después suele generar más trabajo.

Contenido

Cuando la función de la página está clara, puedes trabajar lo que debe explicar.

Aquí entran H1, encabezados, texto, ejemplos, evidencias, enlaces, imágenes y CTA. Todos deberían contribuir a que esa URL cumpla la misma función, no optimizarse como piezas aisladas.

Medición

Después observas qué está ocurriendo.

Consultas, impresiones, clics, páginas que aparecen y otros datos pueden ayudarte a confirmar o cuestionar la hipótesis con la que trabajaste. El dato abre nuevas decisiones; no sustituye el criterio.

La técnica atraviesa todo el modelo. La página necesita unas condiciones mínimas para ser descubierta, rastreada, procesada e indexada cuando corresponda. La documentación de Google sobre cómo funciona la Búsqueda distingue distintas fases como rastreo, indexación y presentación de resultados; superar una no garantiza automáticamente aparecer para una consulta determinada.

Esa capa técnica no compite con intención o contenido. Responde a otro tipo de problema.

Qué áreas forman parte del SEO

El SEO toca varias capas de una web. No porque debas trabajar todas al mismo tiempo, sino porque el problema puede encontrarse en lugares distintos.

Investigación e intención. Ayudan a entender qué demanda existe, cómo busca la gente y qué necesidad hay detrás de una consulta.

Arquitectura. Decide qué páginas necesita la web, cómo se organizan y cómo se relacionan mediante navegación y enlaces internos.

Contenido y SEO on-page. Trabajan la respuesta concreta de cada URL: title, H1, estructura, texto, imágenes, anchors, señales de confianza y siguiente paso.

SEO técnico. Revisa condiciones como descubrimiento, rastreo, indexabilidad, canonicalización, renderizado o problemas de rendimiento cuando afectan al acceso o a la experiencia.

Medición. Permite observar consultas, páginas, impresiones y clics para convertir el trabajo anterior en nuevas hipótesis y decisiones.

No es una clasificación cerrada: según el proyecto también pueden entrar áreas como autoridad, SEO local o SEO internacional.

Estas áreas se relacionan, pero no pesan igual en todos los casos.

Si una página no debería existir, optimizar su metadescripción no resuelve el problema.

Si la URL adecuada existe pero tiene un problema de acceso o indexabilidad, reescribir tres párrafos tampoco.

Si puede procesarse correctamente pero responde a otra necesidad, instalar otro plugin no corrige esa desconexión.

Por eso SEO tampoco significa:

• conseguir todas las luces verdes de un plugin;
• repetir una keyword hasta alcanzar una densidad;
• escribir únicamente para un buscador;
• crear contenido por sistema;
• aplicar una lista fija de factores en el mismo orden.

Las herramientas pueden facilitar tareas. No deciden por ti qué problema merece resolverse primero.

SEO y SEM no son lo mismo

SEO y SEM están relacionados con la visibilidad en buscadores, pero no describen exactamente el mismo trabajo.

SEO trabaja principalmente la visibilidad orgánica. En muchos contextos actuales de marketing digital en español, SEM suele utilizarse para referirse a publicidad en buscadores.

Ambos pueden convivir dentro de una estrategia, pero funcionan mediante mecanismos diferentes. Pagar por aparecer mediante un anuncio no es hacer SEO, y trabajar SEO no garantiza una posición orgánica determinada.

Para empezar, esa frontera es suficiente. La comparación detallada entre ambos canales merece una guía propia.

Qué deberías trabajar primero si estás empezando

Cuando una web tiene muchas cosas que podrían optimizarse, no siempre conviene empezar por la más visible ni por la que una herramienta marque primero.

Yo prefiero buscar qué incertidumbre puede invalidar más decisiones posteriores.

Puedes orientarte así:

Si todavía no sabes qué necesidad debe resolver la página, revisa primero la búsqueda y la intención. Antes de optimizar el texto necesitas saber qué tarea debería cumplir.

Si entiendes la necesidad, pero no sabes qué URL debería responder, revisa arquitectura y función de página. Crear otra URL sin resolver eso puede aumentar el solapamiento.

Si existe un problema de descubrimiento, rastreo o indexación, entra en la capa técnica. No tiene sentido corregir copy esperando resolver un bloqueo de acceso.

Si Google está mostrando otra URL de tu web para la búsqueda que estás investigando, comprueba si ambas páginas se solapan, si la arquitectura deja clara su función y si la intención asignada a cada una tiene sentido.

Si una URL obtiene impresiones pero pocos clics, investiga las consultas, el contexto actual de la SERP y cómo se presenta tu resultado antes de atribuirlo automáticamente al contenido completo de la página.

Si llega tráfico a la URL adecuada pero la página no resuelve bien la tarea, entonces el foco puede estar en contenido, claridad, UX, evidencia o siguiente paso.

No son diagnósticos automáticos. Son puertas de entrada para evitar tocar diez cosas a la vez.

La primera tarea debería reducir la incertidumbre más importante.

Si todavía no sé qué URL debería responder, prefiero resolver eso antes de dedicar tiempo a afinar su metadescripción. Si existe un bloqueo técnico claro, empiezo ahí. Si la página correcta ya aparece para consultas relevantes, entonces puedo investigar el siguiente nivel del problema.

Volvamos a las luces verdes del principio.

Rank Math puede ayudarte a implementar y comprobar determinados elementos. Una herramienta de keywords puede aportar estimaciones. Search Console puede mostrar datos de tu propiedad. Un crawler puede revelar problemas técnicos.

Pero ninguna sustituye la pregunta previa:

¿qué problema SEO estoy intentando resolver?

Cuando puedes responderla, el trabajo deja de ser una sucesión de cambios sueltos y empieza a tener un orden más útil:

entender → diagnosticar → priorizar → actuar → medir.

Si quieres continuar aprendiendo, los siguientes pasos naturales son profundizar en intención de búsqueda, entender la diferencia entre SEO y SEM o aprender qué pregunta debería responder cada herramienta SEO.

Y si prefieres aplicarlo directamente a tu web, podemos trabajarlo en una clase online 1:1. Tú compartes pantalla y ejecutas sobre tu propio proyecto; yo te ayudo a identificar qué revisar primero, explico el porqué de cada decisión, reviso lo que haces y corregimos juntos lo que necesite otra vuelta. La idea es que entiendas el proceso y ganes autonomía para decidir la siguiente vez.

Dudas habituales sobre SEO

Preguntas frecuentes sobre SEO

Resuelve las dudas más habituales sobre qué significa SEO, para qué sirve, qué diferencia existe con SEM, qué papel tienen los plugins y qué conviene revisar primero cuando estás empezando.

06

preguntas directas

Qué significa, para qué sirve y qué revisar primero.

Qué es un prompt: cómo dar contexto e instrucciones útiles a una IA

“Hazme una página de servicios.”

Eso ya es un prompt.

El problema es que, para una tarea así, todavía deja muchas decisiones abiertas: qué servicio ofreces, para quién debe escribirse la página, qué quieres conseguir, qué información es real y cómo necesitas recibir el resultado.

Un prompt es la entrada que proporcionas a un sistema de inteligencia artificial para iniciar u orientar una tarea. Puede incluir una pregunta, instrucciones, contexto, datos, ejemplos o restricciones que ayuden al sistema a entender qué necesitas.

En un modelo de lenguaje suele ser texto, aunque dependiendo del sistema también puede adoptar otras formas, como una imagen o audio. Las prácticas oficiales de OpenAI sobre prompts utilizan esta idea y distinguen además el prompt concreto del proceso más amplio de Prompt Engineering (ingeniería de prompts).

Para trabajar con una IA en una web, un contenido, SEO o marketing, puedes quedarte con una regla más práctica: un prompt aporta la información necesaria para que la IA trabaje sobre el problema correcto.

Y esa dirección no se mide en palabras.

Un prompt no tiene que ser largo: tiene que ser suficiente.

Qué es un prompt

Un prompt puede ser tan breve como:

Resume este documento en cinco puntos y conserva las cifras importantes.

O puede necesitar algo más de precisión:

Compara estas dos propuestas. Señala diferencias, ventajas, riesgos y datos que faltan. No elijas todavía una ganadora.

Los dos son prompts. Lo que cambia no es que uno sea más profesional que otro, sino cuánta dirección necesita la tarea.

Si acabas de proporcionar un documento y solo quieres resumirlo, una frase puede bastar. Si quieres preparar una página de servicios a partir de una oferta real, habrá más decisiones que definir: público, objetivo, fuentes, límites, estructura y criterios de revisión.

En mi trabajo con webs y contenidos, muchas veces el problema no está en una palabra concreta del prompt. Está antes: todavía no se ha decidido qué debe resolver la página, para quién es o qué información puede utilizar la IA. Añadir instrucciones sin cerrar esas decisiones solo desplaza el problema.

Un prompt puede servir para preguntar, explicar, resumir, comparar, revisar, analizar o generar una primera propuesta. Por ejemplo:

Revisa el primer bloque de esta página de servicios y señala qué partes resultan demasiado genéricas antes de proponer una nueva versión.

Aquí no estás pidiendo simplemente “un texto mejor”. También estás indicando qué debe hacer primero la IA.

Prompt y Prompt Engineering no son lo mismo

Para empezar a utilizar una IA no necesitas convertir cada petición en un ejercicio de ingeniería. Primero conviene saber definir la tarea, aportar la información relevante y revisar la respuesta.

Cuando necesitas diseñar y evaluar instrucciones de forma sistemática, entras en el siguiente nivel: Prompt Engineering.

Qué información puede incluir un prompt útil

Para escribir un prompt útil, define qué quieres conseguir, añade solo el contexto y los datos que cambian la respuesta, indica las restricciones importantes, especifica cómo necesitas recibir el resultado y comprueba después si la salida cumple el objetivo. No todas las tareas necesitan todos esos elementos.

Estas piezas funcionan como un mapa, no como un formulario obligatorio.

Objetivo

El objetivo responde a:

¿Qué necesito conseguir?

Compara:

Escribe sobre SEO.

con:

Explica la diferencia entre una intención informativa y una transaccional con dos ejemplos aplicados a una web de servicios.

En la segunda petición sabemos qué debe explicar, cuántos ejemplos necesita y dónde aplicarlos. Se han cerrado decisiones que afectan directamente a la respuesta.

Contexto y audiencia

El contexto explica sobre qué situación estamos trabajando. La audiencia aclara para quién debe servir el resultado.

Según la tarea, puede importar el tipo de proyecto, el producto o servicio, el punto de partida, el problema, el nivel del lector o la función que tendrá la pieza.

Por ejemplo:

Estoy revisando una página para clases online 1:1. La persona trabaja sobre su propio proyecto y ejecuta los cambios mientras recibe explicación, revisión y corrección.

Ahora la IA ya no tiene que inferir si hablamos de un curso grabado, una agencia o un servicio ejecutado por otra persona.

También cambia la profundidad. No explicarías un concepto SEO de la misma forma a alguien que empieza que a un freelance que ya utiliza herramientas y necesita justificar mejor sus decisiones.

¿Hace falta comenzar cada prompt con “actúa como experto”? No. Un rol puede orientar el enfoque cuando cambia realmente la tarea —por ejemplo, revisar como editor en lugar de generar como copywriter—, pero no sustituye un objetivo, contexto, datos o criterios claros.

“Actúa como experto” delante de una petición ambigua sigue dejando una petición ambigua.

Datos y fuentes

El contexto describe la situación. Los datos establecen con qué información real puede trabajar la IA.

Pueden ser un briefing, un texto existente, documentación, el contenido de una URL —si el sistema puede acceder a ella—, notas, una tabla, cifras confirmadas o requisitos que deben mantenerse.

Esta parte importa especialmente cuando la respuesta podría sonar convincente aunque haya completado un hueco que nunca confirmaste.

Si conoces el método, el público y el servicio de una página pero todavía falta decidir un precio o una condición, puedes establecer:

Utiliza únicamente la información proporcionada. Si necesitas un dato que no está confirmado, indícalo como [PENDIENTE].

[PENDIENTE] no es una función oficial de ChatGPT. Es una convención de trabajo que utilizo para impedir que una ausencia de información se transforme silenciosamente en un hecho.

La regla que intento aplicar es sencilla:

si una decisión cambia el resultado, no conviene dejar que la IA la invente: confírmala, apórtala como dato o déjala pendiente.

Restricciones

Las restricciones responden a:

¿Qué debe respetar la respuesta?

Por ejemplo:

No inventes cifras, testimonios, precios ni resultados.

O:

Mantén los datos existentes y separa hechos confirmados de propuestas.

Una restricción aporta valor cuando evita un error relevante. Acumular prohibiciones por rutina puede hacer el prompt más pesado sin hacerlo más claro.

Formato de salida

El formato responde a:

¿Cómo necesito recibir el resultado para poder trabajar con él?

No es lo mismo pedir:

Analiza esta página.

que:

Devuelve una tabla con problema, evidencia y recomendación.

Tampoco es igual pedir “mejora la estructura” que solicitar un H1 y un esquema H2/H3 explicando la función de cada bloque.

El formato no hace mejor el razonamiento por sí mismo; hace que la salida encaje con el siguiente paso de tu trabajo.

Criterios de revisión

Antes de enviar una tarea compleja, conviene saber:

¿Qué comprobaré para decidir si la respuesta sirve?

Puedes revisar si:

• responde al objetivo;
• utiliza correctamente los datos;
• respeta los límites;
• se entiende para la audiencia prevista;
• separa hechos de información pendiente;
• entrega un formato utilizable;
• permite justificar qué funciona y qué necesita otra vuelta.

Un prompt mejor orientado puede mejorar la respuesta, pero no convierte automáticamente esa respuesta en verdadera. Si incluye hechos, cifras o afirmaciones verificables, todavía debes comprobarlos.

La respuesta de la IA forma parte del proceso. Todavía tienes que decidir si cumple lo que necesitabas.

Un prompt no tiene que ser largo: tiene que ser suficiente

Añadir contexto puede ayudar. Añadir palabras, no necesariamente.

Un prompt largo puede seguir siendo malo si mezcla objetivos, contiene instrucciones contradictorias, incorpora información irrelevante o desactualizada, exige decisiones todavía no tomadas o no permite evaluar la salida.

Imagina que acabas de proporcionar un informe y solo necesitas:

Resume las conclusiones en cinco puntos y conserva las cifras.

No necesitas volver a explicar lo que ya contiene el documento.

En cambio, “hazme una página de servicios” deja abiertas decisiones que sí condicionan la respuesta y merece más dirección.

Antes de añadir otro bloque al prompt, pregúntate:

¿Esta información cambia lo que la IA debe hacer, lo que debe respetar o la forma en que voy a evaluar la respuesta?

Si no cambia ninguna de esas tres cosas, probablemente sobra.

Cómo mejorar un prompt paso a paso

Mejorar un prompt consiste, muchas veces, en diagnosticar por qué la respuesta anterior no resolvió bien la tarea.

Puedes revisarlo en este orden:

1. Aclara la tarea. ¿Quieres ideas, diagnóstico, estructura, borrador, comparación o revisión.

“Mejora esta página” permite muchas interpretaciones. “Detecta primero los problemas de claridad del hero y después propón una versión revisada” define mejor el trabajo.

2. Busca decisiones abiertas. Si la IA tiene que elegir por su cuenta un público, una oferta, una prioridad o un dato que cambia el resultado, comprueba si esa decisión debería estar definida antes.

3. Añade el contexto o las fuentes que faltan. Incluye solo aquello que modifica la respuesta y deja visibles los huecos que todavía no están resueltos.

4. Introduce límites relevantes. Por ejemplo: “No añadas información que no aparezca en las fuentes”.

5. Define la salida. Tabla, outline, diagnóstico, alternativas, HTML o borrador son resultados distintos aunque partan del mismo caso.

6. Revisa y ajusta. Las recomendaciones oficiales de OpenAI para crear buenos prompts insisten en definir con claridad la tarea, aportar el contexto necesario, ajustar el alcance y trabajar de forma iterativa.

El proceso puede resumirse así:

prompt → respuesta → revisión → ajuste

Si el resultado es genérico, quizá falta una decisión o contexto. Si introduce datos que no has dado, revisa fuentes y límites. Si resuelve otra cosa, aclara el objetivo. Si el contenido sirve pero el formato no, cambia la salida solicitada.

Ejemplo: de una petición vaga a una instrucción útil

Volvamos al principio:

“Hazme una página de servicios.”

Es un prompt, pero para una página real deja demasiadas decisiones abiertas. En lugar de convertirlo en una plantilla gigantesca, podemos ver qué añadimos y por qué.

Objetivo

Crea la estructura y un primer borrador de una página de servicios para clases online 1:1 dirigidas a personas que quieren crear o mejorar su web mientras aprenden a gestionarla.

Qué cambia: sabemos qué pieza necesitamos, qué servicio representa y qué debe entender el lector.

Contexto y audiencia

La persona trabaja sobre su propio proyecto mientras recibe explicación, revisión y corrección. Puede partir de una idea o de una web ya publicada.

Qué cambia: ya no hay que imaginar si el servicio es un curso grabado o un trabajo ejecutado por otra persona.

Datos

Utiliza únicamente el briefing proporcionado. Si necesitas información que no está confirmada, márcala como [PENDIENTE].

Qué cambia: existe una fuente de verdad y una forma de gestionar los huecos.

Restricciones

No inventes cifras, testimonios, servicios ni resultados. Mantén un tono claro, profesional y didáctico.

Qué cambia: reduces dos riesgos concretos: inventar información y adoptar un tono que no representa el servicio.

Formato

Propón primero la estructura de la página y explica brevemente la función de cada sección. Después redacta el borrador.

Qué cambia: puedes validar el orden antes de editar el texto línea a línea.

Revisión

Comprueba que cada bloque aporte algo distinto, que el servicio se entienda y que no aparezca información no confirmada.

Qué cambia: ya existe una forma de evaluar el resultado.

Prompt completo

OBJETIVO

Crea la estructura y un primer borrador de una página de servicios para
clases online 1:1 dirigidas a personas que quieren crear o mejorar su web
mientras aprenden a gestionarla.

CONTEXTO Y AUDIENCIA

La persona trabaja sobre su propio proyecto mientras recibe explicación,
revisión y corrección. Puede partir de una idea o de una web ya publicada.

DATOS

Utiliza únicamente el briefing proporcionado.
Si necesitas información que no está confirmada, márcala como [PENDIENTE].

RESTRICCIONES

Escribe en español de España, con un tono claro, profesional y didáctico.
No inventes cifras, testimonios, servicios ni resultados.

FORMATO

Propón primero la estructura de la página y explica brevemente la función
de cada sección. Después redacta el borrador.

REVISIÓN

Comprueba que cada bloque aporte algo distinto, que se entienda cómo
funciona el servicio y que no aparezcan datos no confirmados.

La mejora no está en el número de líneas. Está en que ahora sabemos qué hay que producir, para quién, con qué información, bajo qué límites y cómo revisarlo.

Si trabajas específicamente con textos web, la guía de copywriting con IA desarrolla cómo llevar este criterio al brief, el mensaje, las fuentes y la edición de una pieza.

Qué revisar antes de reutilizar un prompt

Una estructura que funcionó puede ahorrarte trabajo. Antes de reutilizarla, comprueba qué variables han cambiado:

• objetivo;
• proyecto o servicio;
• audiencia;
• fuentes disponibles;
• decisiones pendientes;
• restricciones;
• formato de salida;
• criterios de revisión.

No necesitas rehacer el prompt si esas variables siguen siendo válidas. Sí necesitas actualizarlo cuando el nuevo caso cambia alguna de ellas.

Eso nos devuelve a la frase del principio.

“Hazme una página de servicios” ya era un prompt.

Era insuficiente para esa tarea porque todavía no sabíamos qué página necesitábamos construir, para quién, con qué información ni cómo evaluar el resultado. Al cerrar esas decisiones, la petición se vuelve más útil sin necesidad de convertirla en un documento enorme.

No se trata de escribir más. Se trata de dar la información que cambia la tarea y conservar un criterio para revisar la respuesta.

Si quieres seguir aprendiendo, puedes recorrer las guías del blog sobre IA, SEO, WordPress, copy y diseño web.

Y si quieres aplicar este método a tu propio proyecto, podemos trabajarlo en una clase online 1:1. Tú compartes pantalla y ejecutas sobre tu web, contenido o prompt; yo te ayudo a ordenar la tarea, explico las decisiones, reviso lo que haces y corrijo contigo lo que necesite otra vuelta. El objetivo es que entiendas el proceso y ganes autonomía para enfrentarte al siguiente problema.