PGAS: un servicio diseñado como producto

Resumen

Construí PGAS como un producto, no como una agencia que cotiza. El método VERA convierte visibilidad en buscadores y citas en modelos en entregables fijos, plazos y precios en CLP. El sitio live en pgas.online es la prueba: schema, preguntas como H2 y copy que un modelo puede citar. Lo diseñé yo, Jorge Cortés.

Problema

La demanda de visibilidad se movió. La gente pregunta en ChatGPT, lee Perplexity y se queda en las AI Overviews de Google. El trabajo que las agencias venden no se movió con ella.

La oferta típica sigue siendo SEO de hace cinco años. Palabras clave. Informes. Un PDF. El precio vive detrás de cotizar. El alcance se negocia en una llamada. El método no se ve. El sitio de la agencia no demuestra lo que promete hacerle al cliente.

Eso no es un problema de copy. Es un problema de producto. Si el alcance es líquido, no puedes publicar un número. Si el método es una presentación, no puedes versionarlo. Si el sitio es una landing, no hay evidencia de que sepas construir páginas que un crawler y un modelo puedan usar.

Yo no quería otra agencia. Quería un servicio con SKUs, un sistema ejecutable, y un sitio que sea la demostración de ese sistema. SEO, AEO y GEO son el trabajo que el producto vende. No son el territorio de este caso. Aquí documenté cómo lo empaqueté.

Restricciones

Trabajé solo, como founder e ingeniero de producto. Año 2026. Santiago, Chile. Cobro en CLP — también LATAM, con boleta o factura. Sin permanencia mínima en los planes mensuales. Esas reglas bajan la fricción y obligan a que cada SKU quepa en un número público.

No hay CMS ni base. El stack declarado es Next.js, TypeScript, JSON-LD y Vercel. Inventar un panel o un Supabase habría sido mentir. El contenido vive en el repositorio. Cada página es un artefacto que yo controlo, igual que en este dominio.

Segunda restricción: el grafo. jorgeco.tech es la fuente canónica sobre la entidad Jorge Cortés. PGAS es un producto que esa entidad construyó. El contenido de SEO, AEO y GEO no puede vivir en los dos sitios. Si este dominio publica “cómo aparecer en ChatGPT”, canibaliza a la agencia y ensucia la entidad. El método se explica en el producto; aquí solo cabe cómo lo construí.

Tercera: honestidad de catálogo. Un precio público es una promesa. Para publicarlo congelé entregables. Quince páginas de on-page. Cuatro contenidos al mes. Un diagnóstico en 48 horas. Si el cliente pide más, no es “lo vemos”. Es una orden de cambio. El SKU a medida existe, pero es la excepción al final del catálogo, no el default.

Cuarta: extractabilidad. Las páginas clave tienen que ser citables: lead de 50 a 80 palabras, preguntas como H2, JSON-LD alineado con lo visible. Un lead que responde suena a ficha. Un cuerpo que solo hace voz no se cita. Las dos capas conviven en la misma plantilla.

Ese conjunto es ingeniería de producto: convertir un servicio opaco en un sistema con catálogo, artefactos y un sitio que demuestra el método.

Arquitectura que diseñé

VERA no es un acrónimo de landing. Es el pipeline de entrega. Cada letra tiene ventana, artefactos, tipos de schema cuando aplica, y un KPI. El sitio de PGAS implementa sobre todo Respuesta y Entendimiento. Visibilidad y Autoridad se ejecutan sobre el dominio del cliente. El marketing de PGAS no es el trabajo. Es el banco de pruebas.

Visibilidad — semanas 1 y 2

Artefactos: auditoría técnica, checklist de indexación, on-page sobre un cupo cerrado de URLs, Search Console y GA4, presupuesto de Core Web Vitals, control de crawl. KPI: impresiones y top 10.

En PGAS, Visibilidad también es la navegación. El sitio público tiene Servicios, Método VERA, Precios, Sobre, Blog y Contacto, más páginas de servicio (SEO, AEO, GEO, desarrollo web). Es un motor que crece. No invento un recuento de URLs.

Entendimiento — semanas 2 y 3

Artefactos: un grafo JSON-LD por página. Organization, Service, FAQPage, HowTo, Speakable, Article, más refuerzo de entidad (nombre, marca, relación founder–producto). KPI: schema válido y rich results. Si el marcado no coincide con el HTML, el tipo no cuenta.

El sitio de PGAS es el ejemplo. Las preguntas se escriben como H2, no como un acordeón. El método tiene un resumen ejecutivo arriba. El marcado sigue lo visible. Mismo patrón que aquí: un grafo por página, @id estables, App Router. No es un plugin. Es código.

Respuesta — semanas 3 y 4

Artefactos: plantillas Q&A extractables por un LLM, lead de 50 a 80 palabras al tope de las páginas clave, cobertura de PAA y snippets, loop de mención cada quince días. KPI: snippets más citas en modelos. El loop, hoy, es en parte manual. El método lo dice: tracking quincenal a mano. Eso es un hueco de producto.

Autoridad — desde el mes 2

Artefactos: menciones off-site, datos originales que valga citar, directorios que los modelos leen, seguimiento de AI Overviews. KPI: Overviews más dominios que enlazan. Esta fase no cabe en un one-shot de dos semanas. Por eso el catálogo separa implementación (SEO técnico, AEO+GEO, pack web) de los planes mensuales. Autoridad es un loop, no un SKU de lanzamiento.

El diagrama es el orden de construcción. Autoridad no se pide si Visibilidad no indexa. Entendimiento no se marca si el HTML no sostiene los tipos.

Stack y por qué

Next.js porque el sitio es el producto y el producto es páginas. App Router, una ruta por artefacto, metadata por página, el mismo patrón que jorgeco.tech.

TypeScript porque el catálogo, los tipos de schema y las rutas son contratos. Un precio mal tipeado en un PDF se arregla con otro PDF. Un precio mal tipeado en código se ve en el build. El pack Web+SEO+AEO declara Next.js, schema precargado y deploy en Vercel. El stack que vendo en ese SKU es el stack con el que está hecho PGAS.

JSON-LD a mano, en el grafo de cada página, porque AEO y GEO son el trabajo. Si el marcado sale de un plugin, no puedo versionarlo ni validarlo contra el HTML. Los tipos que el método nombra tienen que ser código revisable.

Vercel porque el ciclo es Think / Build / Ship. Preview por rama, producción, sin un servidor que yo administre.

No hay Supabase. No hay CMS. El motor crece en el repo. Eso limita quién edita copy. A cambio, cada URL es un commit. Para un sitio citable, prefiero esa fricción.

Decisiones técnicas

La decisión que ordena el resto: el catálogo es el producto. La ruta /precios tiene un H1 que nombra SEO, AEO y GEO en pesos chilenos. El Diagnóstico Express está publicado a $79.000 CLP en 48 horas: PDF, una llamada de 30 minutos, y las cinco oportunidades principales en Google, ChatGPT, Perplexity y Gemini. Ese SKU existe para comprar un primer corte sin una reunión de venta.

El resto de one-shots congela plazo y entregable igual que el diagnóstico. El proyecto a medida aparece al final. Cotizar es el overflow, no el default.

Los planes mensuales (Esencial, Visibilidad, Crecimiento) no piden permanencia. Puedo cambiar una promo en un solo lugar porque el precio es dato, no un PDF. El día que observé el sitio, los primeros diez diagnósticos salían gratis. Eso no es el producto. Es la prueba de que la oferta se edita donde vive el catálogo.

El diagnóstico se acredita al 100% si contratas implementación en 30 días. Lo menciono una vez, como ingeniería de la oferta: baja el costo de probar el SKU de entrada. No es un cupón. Es una regla del sistema de precios.

Segunda decisión: dos dominios, dos trabajos. El producto habla del método y vende el servicio. Este dominio habla de quién lo construyó. El footer de PGAS dice “Creada por Jorge Cortés” y enlaza al founder. Esta página cierra el sentido contrario, sin repetir el blog de la agencia.

Tercera: extractabilidad como plantilla. El lead de 50 a 80 palabras responde la pregunta de la página. El cuerpo conserva la voz. Las FAQ son H2. Un modelo que resume la página tiene un bloque corto arriba y preguntas con forma de pregunta. Eso es Respuesta en el markup.

Cuarta: un grafo por página. Inferí el mismo patrón que uso aquí. Tipos que el HTML sostiene. Nada de Speakable sobre un párrafo que no se lee en voz alta. Nada de FAQPage si las preguntas no están en el documento. El drift de schema es un fallo de release.

Quinta: el sitio como laboratorio. Cada plantilla nueva es un experimento de extractabilidad. El motor crece porque el método necesita superficie, no porque un blog deba publicar por calendario.

Problemas que aparecieron

El primero fue de arquitectura de contenido. Si explico VERA con profundidad aquí, este dominio se vuelve un segundo blog de SEO. Si no explico nada, el caso no demuestra ingeniería.

El segundo es el trade-off del catálogo. Las agencias esconden el precio porque el alcance varía. Si congelo quince páginas, cuatro contenidos y 48 horas, el número público es honesto. Si un cliente llega con un sitio de 80 URLs y tres idiomas, el SKU ya no cabe. La presión natural es estirar el entregable y dejar el precio. Eso pudre el catálogo. El problema es no tener un mecanismo de cambio de alcance.

El tercero es de voz. Un lead escrito para ser citado se lee a veces como ficha. Las H2 en forma de pregunta se leen como FAQ de soporte. Si suelto la voz en el lead, el modelo cita un párrafo que no responde nada. Si suelto la extractabilidad en el cuerpo, el sitio parece un manual.

El cuarto es drift de schema. HowTo, Speakable, FAQPage y Article son fáciles de invalidar. Cambias un H2, dejas el JSON viejo, y el tipo miente. Sin una puerta en el release, el grafo se pudre en silencio.

El quinto es medición de citas. El método pide tracking quincenal de menciones en ChatGPT y Perplexity. Hoy eso es, en parte, una persona preguntándole a un modelo y anotando. No escala. Es el hueco más honesto del producto.

Cómo los resolví

1. 01/
   Partí el grafo en dos dominios. SEO, AEO y GEO viven en el producto. Este dominio solo publica el caso de constructor. La ficha de Jorge Cortés enlaza el producto; el producto enlaza al founder. Nadie duplica posts.
2. 02/
   Congelé entregables por SKU. Quince páginas, cuatro contenidos, 48 horas. El extra es orden de cambio, no una cotización difusa. El proyecto a medida quedó como SKU de desborde al pie del catálogo.
3. 03/
   Separé el lead del cuerpo en la plantilla. El bloque de 50 a 80 palabras responde. El resto sostiene la voz. Las preguntas visibles son H2, alineadas con FAQPage.
4. 04/
   Traté el schema como contrato de release. El HTML manda. El JSON-LD replica. Si no puedo validar el tipo, no lo publico. La automatización de esa puerta todavía no está cerrada.
5. 05/
   Dejé el tracking de citas como loop manual y lo marqué como deuda. No vendí un dashboard que no existe. El método dice “quincenal” y “manual”. El producto tiene que crecer hacia un registro estructurado.

El crédito del diagnóstico a 30 días y la ausencia de permanencia mínima bajan la fricción de entrar sin diluir el SKU. El precio público aguanta porque el alcance está cerrado.

Resultado

PGAS está live. El catálogo público cobra en CLP. El diagnóstico de entrada se entrega en 48 horas. VERA tiene cuatro fases y un KPI por fase. Eso es todo lo que puedo afirmar sin inventar clientes, rankings, tráfico ni ingresos.

Diagnóstico publicado

48 h

Precios a la vista

CLP

Fases VERA con KPI

4

Estado

Live

El resultado estructural: un servicio que se compraba como cotización ahora se lee como catálogo. Un método que era una charla ahora es un pipeline con artefactos. Un sitio de agencia ahora es la demostración de Respuesta y Entendimiento. El Diagnóstico Express a $79.000 CLP hace observable esa tesis: se puede comprar un corte en 48 horas sin pedir una propuesta.

No constan clientes ni posiciones.

Evidencia

Producto live: pgas.online. Una sola salida. El footer atribuye la autoría a Jorge Cortés. Este caso documenta cómo lo empaqueté.

Qué haría distinto

El tracking de citas no puede seguir siendo una ronda quincenal en la cabeza de alguien. Lo que construiría ahora es un registro estructurado: fecha, modelo, prompt, si citó, URL citada, captura. Una planilla con esquema, no un recuento oral. Si esa herramienta ya existe en la operación, este párrafo sobra.

Schema drift: no lo dejaría a una pasada manual. Lo pondría como puerta de release. Rich Results Test o un validador en CI sobre las rutas que declaran FAQPage, HowTo y Speakable. Inferí esa puerta porque es lo que el grafo exige. No afirmo que hoy corre sola.

La longitud del lead debería ser un campo de plantilla. 50 a 80 palabras es la regla del método. Quiero verla fijada en cada tipo de página, con un chequeo en el build.

Contaría las URLs indexables y las publicaría como métrica de motor. Hoy no lo hago porque no tengo el número cerrado.

Mantendría la separación de dominios. No escribiría un blog de SEO en jorgeco.tech aunque rankee. Si algo uniría, sería un módulo de hechos de entidad, no los posts del método.

El catálogo lo dejaría público. Cambiaría el desborde: un configurador mínimo para el SKU a medida (páginas, idiomas, plazo) que calcule un rango, no un cotizar opaco.