PLAN SEO DEFINITIVO WIC

Fuente única de verdad para construcción, SEO, URLs, revenue y seguimiento

Sitio: whatsincabo.com
Fecha de cierre estratégico: 2026-06-30

Última actualización formal de estado: 2026-07-26 UTC

Estado: documento canónico operativo. Reemplaza como roadmap a los reportes SEO previos.

Última revisión adversarial integrada: 2026-07-02 — se integró el acuerdo Luis + Claude + Codex sobre guías, beaches, attractions y fichas: guías nuevas bajo /guides/{slug}/, guías existentes sin mover, beaches bajo /things-to-do/beaches/, rechazo de /attractions/{slug}/{id}/, y reafirmación de /listing/{slug}/{id}/ como target neutral para todas las entidades si el canary pasa. Esta revisión mantiene la decisión del 2026-07-01 sobre migrar temprano a /listing/ solo después de auditoría, staging, canary y smoke limpio.

Actualización 2026-07-22: Cabo Real V3.1 quedó aprobado y publicado en su URL existente; /golf/ y /guides/best-golf-courses-in-cabo/ están 200, indexables y en sitemap; /guides/ tiene nueve cards. Se creó el sistema independiente wic-golf-listing para continuar campo por campo sin reutilizar datos, fotos o geometría. La arquitectura aprobada no cambió: el canary global /listing/ continúa bajo gate y no existe autorización de migración masiva.

Actualización 2026-07-26 — LA MIGRACIÓN /listing/ SE EJECUTÓ. Este es el cambio de estado más importante desde el cierre del plan, y deja obsoleto todo el lenguaje de "canary pendiente" que aparecía en las secciones 0, 3.1 y 5.

• El mecanismo (wic-neutral-urls.php, flag por ficha _wic_neutral_url) se había desplegado el 2026-07-03 y llevaba 22 días vivo con 5 fichas cuando se auditó. El gate 11.2, tal y como estaba redactado ("autorización previa al canary"), describía una decisión ya tomada.
• Evidencia del go/no-go: GATE-11.2-EVIDENCIA-CANARY-LISTING-2026-07-25.md — el canary pasaba 10 de 11 checks verificables.
• Con autorización expresa de Iván se ejecutó la migración por lotes el 2026-07-26, en el orden del §5.6 (verticales pequeñas → hoteles/playas → restaurantes al final):

Estado: 240 de 257 fichas (93%) en /listing/{slug}/{id}/. Las 17 de golf quedaron deliberadamente fuera y siguen en /golf-courses/{slug}/: otro equipo trabaja esa vertical y su migración exige coordinación aparte.

Trabajo asociado, todo verificado y registrado en EXECUTION-LOG-CODEX.md:

• 437 enlaces internos corregidos en 10 páginas, en forma absoluta y relativa.
• Tres fuentes distintas de URLs escritas a mano, encontradas en cascada: un mu-plugin (wic-best-restaurants-itemlist.php), el contenido de las páginas (post_content y _elementor_data), y el child theme (inc/wic-editorial-widgets.php). Las tres se corrigieron para derivar de get_permalink(), así que no vuelven a pudrirse.
• Bug preexistente corregido: el breadcrumb etiquetaba como "Restaurants" a 129 de 257 fichas porque wic_breadcrumb_type_config() solo cubría 5 de 10 listing types. Se corrigieron 111; las 17 de golf siguen mal y son del otro equipo.
• El home no se tocó: es Elementor y sus widgets leen get_permalink(), así que se autocorrigió.

Consecuencia arquitectónica: al liberarse los namespaces tipados, /hotels/ y /transportation/ quedan disponibles para construirse como hubs verticales (§3.2), cosa que antes era imposible porque el segmento estaba ocupado por las fichas.

Regla: si otro reporte contradice este documento, se trata como histórico hasta que este plan sea actualizado formalmente.

0. Resumen ejecutivo

WhatsInCabo ya tiene una base real: 257 fichas publicadas, 17 drafts controlados, Passport activo, hubs de guías y golf, skills de creación, Cabo Real V3.1 publicado con QA automatizado, WordPress + MyListing + Rank Math y una arquitectura editorial funcionando. El problema principal no es “falta de páginas”: todavía falta autoridad externa, cerrar los revenue rails B2B y aprobar la medición GA4 por entidad.

La estrategia definitiva se ordena en carriles paralelos:

1. Autoridad orgánica continua desde el día 1: GBP, citations, outreach a negocios listados, PR local, cero links comprados. Este es el cuello de botella real de un sitio DR0; publicar más páginas no crea autoridad externa.
2. Revenue y medición en paralelo: /cabo-passport/ ya está activo; /business/, /partners/, SMTP y el contrato GA4 siguen abiertos.
3. Limpieza de índice inteligente: la primera clasificación masiva y 26 merges ya se ejecutaron. Se mantienen fuera del índice facetas, parámetros y páginas thin; cualquier promoción futura pasa ledger.
4. Ledger editorial: ninguna página nueva se construye por intuición; pasa por demanda, inventario, calidad y revenue path.
5. Páginas SEO selectivas: construir solo lo que ya tiene inventario y propósito.
6. Listings neutrales como target: /listing/{slug}/{id}/ queda aprobado como arquitectura ideal. Sí conviene preparar y validar temprano, porque 257 fichas son más manejables que 700, 1,000 o 7,000; pero el canary exige liberar el gate 11.2 y cualquier ampliación posterior exige otro go/no-go humano.

La decisión más importante sobre listings:

Arquitectura aprobada:      /listing/{slug}/{id}/
Estado en producción:       EJECUTADA — 240 de 257 fichas (93%) al 2026-07-26.
Pendiente:                  17 fichas de golf en /golf-courses/{slug}/, fuera por
                            coordinación con el equipo que lleva esa vertical.
Cómo se hizo:               canary de 5 fichas (2026-07-03) + 3 lotes verificados
                            uno por uno, con backup, mapa congelado y rollback por ficha.
Lo que sigue siendo cierto: ninguna ficha se mueve sin pre-flight de enlaces,
                            verificación completa y rollback disponible.

1. Snapshot vivo del sitio

Estado reconciliado con verificaciones WP-CLI, HTTP y navegador al 2026-07-22 UTC.

1.1 Inventario job_listing

Total actual: 257 publicadas + 17 drafts = 274 job_listing. Las sumas por tipo publicadas dependen de _case27_listing_type.

Baseline SEO de referencia: el sitio parte de autoridad externa muy baja/DR0 y con impresiones orgánicas todavía concentradas en pocas URLs. Por eso el plan no se mide por “más páginas publicadas”, sino por autoridad legítima, indexación limpia, revenue rails medidos y primeras impresiones no-marca.

1.2 Estado de páginas clave

1.3 Passport / CTAs

2. Decisiones finales cerradas

2.1 Luis: qué estaba bien

Luis sí tiene razón en varios puntos importantes:

• Separar guías curadas, directorio, listings, business, partners y Passport.
• Pensar las fichas como entidades, no como categorías.
• Proponer una estructura neutral para listings como destino.
• Pedir que el contenido curado tenga un contenedor editorial claro (/guides/) para que usuarios, bots e IA distingan guía editorial de ficha/listado.
• Separar conceptualmente lugares visitables de experiencias reservables: una playa no es lo mismo que un tour pagado, aunque ambos puedan vivir dentro del paraguas "things to do".
• Controlar facetas y parámetros de /explore/.
• Crear /business/ como intención B2B clara.
• Usar gates de inventario antes de indexar páginas.
• Evitar que taxonomías automáticas creen thin content.

2.2 Luis: qué no se ejecuta tal cual

No se aprueba:

• Migrar 257 fichas directo a /listing/ sin prueba, staging, smoke ni rollback.
• Mover guías ya publicadas a /guides/....
• Crear /attractions/ ahora como silo principal sin KWR propio.
• NO crear fichas canónicas en /attractions/{slug}/{id}/.
• NO crear /beaches/ top-level como vertical independiente si el hub aprobado es /things-to-do/beaches/.
• Crear directorio programático anidado completo ahora.
• Indexar facetas o taxonomías sin contenido editorial.
• Clonar páginas por cada combinación zona/cocina/best-for.
• Comprar links o usar PBNs.
• Usar aggregateRating sin reseñas first-party reales.

2.3 Decisión definitiva sobre /listing/

La investigación de destinos comparables cambió el matiz y cerró el debate:

• El DMO oficial del mercado, Visit Los Cabos, usa /listing/{slug}/{id}/ para fichas de negocio/lugar. Ejemplo verificado 200 OK: https://www.visitloscabos.travel/listing/cocina-de-autor/1283/.
• Visit Florida, Visit Las Vegas, Go Hawaii y Denver usan variantes de /listing/{slug}/{id}/.
• Discover Puerto Rico usa /profile/{slug}/{id}.
• Visit Dubai usa /places-to-visit/{slug}.
• Lonely Planet usa /points-of-interest/{slug}/{id}.

Por eso, para WIC multi-vertical:

/listing/{slug}/{id}/

queda aprobado como target estratégico preferido sobre /place/{slug}/.

Razones:

• Está más alineado con DMOs/directorios.
• El ID protege contra colisiones de slug entre verticales y contra cambios de slug. Corrección factual 2026-07-26: la redacción anterior afirmaba que ese riesgo ya era real en WIC. No lo era. La auditoría previa a la migración midió cero colisiones entre las 257 fichas publicadas, y además son estructuralmente imposibles: todas viven en un solo CPT (job_listing), así que WordPress ya garantiza la unicidad del slug. El {id} sigue siendo la decisión correcta —es el patrón de los DMOs comparables, sobrevive a un cambio de slug y permite que la URL neutral resuelva por ID— pero es un seguro a futuro, no la solución a un problema presente.
• /listing/ ya existe como namespace reconocido por el sitio, pero hoy funciona como origen de redirect hacia URLs por tipo; convertirlo en canónico es justo lo que el canary debe probar.
• Evita confusión con place interno de MyListing, que en WIC se usa para restaurantes/lugares.
• Sirve para fichas que cruzan categorías: hotel + restaurante, beach club + nightlife, marina + tours.

Pero:

Target aprobado ≠ migración aprobada.

Interpretación correcta: no significa “no mover”. Significa “mover bien”.

Luis tiene razón en el punto operativo: si el destino final será /listing/{slug}/{id}/, es mejor validar y ejecutar esa migración cuando hay 257 fichas que cuando existan 700, 1,000 o 7,000. También tiene razón en que las nuevas URLs necesitan tiempo para asentarse. El trabajo técnico se prepara en paralelo, pero el canary no se ejecuta hasta liberar el gate 11.2.

Rationale SEO: esperar unas semanas para probar no “pierde” autoridad por sí mismo. Google Search Central documenta que los redirects permanentes 301/308 son señales para que el destino sea tratado como canonical; una migración bien hecha con 301/308, canonical, sitemap, internal links y schema consistentes transfiere las señales modernas de canonicalización. El riesgo no es esperar, sino ejecutar mal la migración, crear cadenas, perder canonicals, romper schema, duplicar URLs o no poder revertir. Por eso se prueba primero; si el canary pasa, la recomendación cambia a migrar las fichas actuales por lotes antes de que el sitio escale demasiado.

La migración global solo se aprueba después de:

1. auditoría técnica;
2. staging;
3. canary 5-10 fichas;
4. smoke;
5. monitoreo;
6. plan de rollback.

Decisión operativa:

EJECUTADO 2026-07-26. La secuencia que se siguió, y que queda como
procedimiento para cualquier migración futura de URLs:

  auditoría → mecanismo con flag reversible por ficha → canary → verificación
  → go/no-go humano → lotes de menor a mayor riesgo → verificación por lote

Lo aprendido y que NO estaba en el plan original: el pre-flight de enlaces
internos es la parte cara, no el cambio de URL. Hay que barrer mu-plugins,
plugins, tema padre e hijo INCLUIDOS SUS SUBDIRECTORIOS, post_content,
_elementor_data y metas de schema — y siempre en forma absoluta Y relativa.
En esta migración aparecieron tres fuentes distintas, en cascada.

2.4 Matriz final: qué se adopta de Luis, qué se adapta y qué se rechaza

2.5 Regla de oro post-investigación

La estructura final sí se debe fijar pronto.
La migración sí se debe ejecutar temprano si el canary pasa.
La indexación programática no se escala sin gates.
La autoridad se construye con relaciones reales, no con URL strings ni links comprados.
La medición se ancla a entidades, no a paths.

3. Arquitectura SEO final

Esta sección es la única arquitectura de URLs operativa. No debe existir otro .md paralelo de estructura URL que compita con este plan. El HTML es la vista visual para socios; este .md es el archivo que las IAs y el equipo deben leer y seguir.

3.0 Reglas generales de URLs

Mapa operativo de la estructura

whatsincabo.com/
├── {vertical}/                              hub de todo Cabo
│   └── {umbrella}/                          categoría/intención aprobada por ledger
├── {zona}/                                  hub regional cross-vertical
│   └── {vertical}/
│       └── {umbrella}/
├── guides/                                  hub editorial activo
│   └── {slug}/                              estándar para guías nuevas
├── things-to-do/
│   └── beaches/                             hub/listado aprobado de playas
├── listing/{slug}/{id}/                     ficha neutral futura; todavía gated
├── explore/                                 discovery; filtros no son landings SEO
├── cabo-passport/                           revenue activo
├── business/                                B2B pendiente
└── partners/                                partnerships pendiente

Separación obligatoria:

Dominio y destino

whatsincabo.com ya implica Los Cabos. Por eso no se usa /los-cabos/ como prefijo del destino general.

Correcto:

/restaurants/
/restaurants/fine-dining/
/things-to-do/
/things-to-do/beaches/

Incorrecto:

/los-cabos/restaurants/
/los-cabos/restaurants/fine-dining/

Gramática de hubs/listados

La gramática para hubs, listados y umbrellas es:

/[{zona}/]{vertical}/[{umbrella}/]

Interpretación:

• sin {zona} = todo Cabo / destino implícito;
• con {zona} = esa zona específica;
• {vertical} = tipo de hub: restaurants, hotels, things-to-do, nightlife, tours, golf, transportation;
• {umbrella} = categoría, cluster o intención indexable solo si pasa ledger;
• el núcleo {vertical}/{umbrella} no se corta: la zona se prefija cuando hace falta.

Ejemplos correctos:

/restaurants/
/restaurants/fine-dining/
/cabo-san-lucas/
/cabo-san-lucas/restaurants/
/cabo-san-lucas/restaurants/fine-dining/
/san-jose-del-cabo/restaurants/
/things-to-do/beaches/

Lectura práctica:

• /restaurants/ = restaurantes en Cabo / Los Cabos como destino implícito.
• /restaurants/fine-dining/ = fine dining en todo Cabo.
• /cabo-san-lucas/ = hub de región, cross-vertical.
• /cabo-san-lucas/restaurants/ = restaurantes en Cabo San Lucas.
• /cabo-san-lucas/restaurants/fine-dining/ = fine dining en Cabo San Lucas.
• /things-to-do/beaches/ = hub/listado de playas bajo el paraguas things-to-do.

Reglas base de indexación

Reglas duras:

• nunca canonical al padre cuando la página es un subset distinto;
• no poner URLs noindex en sitemap;
• no crear URL sin ledger;
• no publicar facetas infinitas;
• no usar /attractions/{slug}/{id}/ como ficha;
• no crear /beaches/ top-level mientras el hub aprobado sea /things-to-do/beaches/.

3.1 Entidades / fichas individuales

Forma canónica, ya en producción:

/listing/{slug}/{id}/

Estado al 2026-07-26: 240 de 257 fichas migradas. Las URLs tipadas viejas siguen vivas como origen de 301 de un salto hacia la nueva.

Único namespace tipado que queda:

/golf-courses/{slug}/     17 fichas — pendiente de coordinar con el equipo de golf

Regla vigente: cualquier ficha que se migre después de esta fecha —las de golf incluidas— pasa por el mismo procedimiento: pre-flight de enlaces sobre todas las fuentes posibles, backup, mapa viejo/nuevo congelado, verificación completa y rollback por ficha.

Nota técnica resuelta: el drift entre /hotels/{slug}/ (ficha en producción) y /hotels/ (hub del diseño) se disolvió con la migración. El namespace tipado dejó de ser canónico, así que /hotels/ y /transportation/ quedan libres para construirse como hubs.

Regla de entidad:

Una entidad = una ficha canónica.

La ficha no cambia de URL por vivir en varias categorías. Ejemplos:

• una playa puede aparecer en /things-to-do/beaches/, en una guía de snorkeling y en un hub de Tourist Corridor;
• un restaurante puede aparecer en Mexican, fine dining, Michelin y Cabo San Lucas;
• un beach club puede ser nightlife, day pass, restaurant y beachfront.

En todos los casos, la entidad debe apuntar a una sola URL canónica futura:

/listing/{slug}/{id}/

La semántica de tipo vive en schema (Restaurant, Beach, Hotel, TouristAttraction, etc.), taxonomías, breadcrumbs, hubs e internal links; no en namespaces separados de ficha.

3.2 Hubs por vertical

Los tipos sí viven en hubs, navegación y páginas de descubrimiento. Los hubs no son fichas; son puertas de entrada editoriales/directory con filtros controlados.

/restaurants/
/hotels/
/things-to-do/
/things-to-do/beaches/
/nightlife/
/tours/
/golf/
/transportation/

Decisiones específicas:

• /restaurants/ = hub de restaurantes del destino.
• /{zona}/restaurants/ = hub de restaurantes por zona cuando el ledger lo apruebe.
• /things-to-do/ = paraguas de cosas que se visitan, hacen o reservan.
• /things-to-do/beaches/ = hub aprobado de playas. Sustituye /beaches/ top-level y /attractions/beaches/.
• /attractions/ = no crear ahora. Solo se reabre si KWR valida una intención propia de attractions/landmarks/viewpoints y se define como hub, no como ficha.
• /listing/{slug}/{id}/ = ficha neutral futura de cualquier entidad que aparezca dentro de esos hubs.

Cada hub indexable debe tener:

• H1 claro;
• intro editorial única;
• enlaces a guías principales;
• enlaces a fichas fuertes;
• filtros útiles sin generar facetas indexables infinitas;
• schema de CollectionPage/ItemList si aplica;
• self-canonical;
• CTA de negocio o Passport cuando corresponda.

3.3 Guías editoriales

Las guías son el formato SEO principal:

Existentes, NO migrar ahora:
  /best-restaurants-in-cabo/
  /best-tacos-in-cabo-san-lucas/
  ...otras guías ya publicadas en raíz

Nuevas, estándar aprobado y soportado por `wic-vertical-guide` v0.7.0:
  /guides/best-restaurants-in-cabo-san-lucas/
  /guides/best-restaurants-in-san-jose-del-cabo/
  /guides/where-to-stay-in-cabo/
  /guides/best-hotels-in-cabo/
  /guides/best-beaches-in-cabo/
  /guides/michelin-guide-restaurants-los-cabos/

NO CREAR — ya existen en raíz, indexadas y en sitemap:
  /best-seafood-in-cabo/
  /best-romantic-restaurants-in-cabo/
  /best-restaurants-in-cabo/
  /best-tacos-in-cabo-san-lucas/

Corrección 2026-07-26: la lista anterior incluía /guides/best-seafood-in-cabo/ y /guides/best-romantic-restaurants-in-cabo/ como guías a construir, cuando sus equivalentes en raíz ya están publicados, indexados y en el sitemap. Construirlas habría sido canibalizar páginas propias, y además el §9.2 prohíbe mover las existentes. Quedan retiradas de la lista de pendientes.

/guides/ ya funciona como hub curado, 200/indexable y con nueve cards públicas. La novena enlaza la guía aprobada /guides/best-golf-courses-in-cabo/. No se migran guías actuales.

Decisión operativa:

• Mantener /guides/ como hub 200/indexable.
• Enlazar ahí las guías ya publicadas.
• No cambiar URLs existentes como /best-tacos-in-cabo-san-lucas/ solo por estética.
• Para guías nuevas, el estándar queda fijado en /guides/{slug}/ y wic-vertical-guide v0.7.0 ya implementa el flujo draft/review/publish y sus gates.
• La guía de golf está aprobada, indexable y en sitemap. Su ItemList organiza necesidades de viaje; no declara una clasificación de calidad.
• Cuatro guías flat permanecen indexables. Seis guías bajo /guides/ están follow,noindex hasta revisión y aprobación explícita de Iván; el flip-pack moderno cubre las seis.
• Si por una razón excepcional una guía nueva debe quedar en raíz, requiere aprobación explícita en el ledger editorial y justificación de no competir con /guides/.
• Si algún día se migran guías antiguas, hacerlo con 301 1:1, sitemap, canonical y GSC, igual que listings.

Relación hub vs guía:

• /things-to-do/beaches/ = hub/listado de playas con filtros, mapa, seguridad y enlaces a fichas.
• /guides/best-beaches-in-cabo/ = guía curada editorial con criterio, ranking/selección y recomendaciones.
• /restaurants/ = hub/directorio.
• /guides/best-restaurants-in-cabo-san-lucas/ = guía curada.

Nunca usar una guía como sustituto de una ficha ni una ficha como sustituto de una guía.

3.4 Directorio, búsqueda y facetas

/explore/
/search/

Uso: UX, mapa, filtros y discovery.

Reglas:

• /explore/ puede indexar solo si se convierte en hub real con H1, intro única, enlaces curados, verticales aprobadas, contenido propio y schema adecuado.
• /explore/?type=..., ?sort=..., ?region=..., ?pg=..., combinaciones y variantes de filtros no son landing pages SEO.
• Los parámetros quedan fuera de sitemap e index. Si aparecen en logs/GSC con rastreo excesivo, se evalúa robots.txt o mover filtros no SEO a fragmentos.
• Taxonomías sin contenido premium a noindex,follow, merge o replace-with-guide.
• Taxonomías fuertes sí pueden quedarse indexables, pero solo después de convertirse en landings útiles.

Taxonomías que pueden ser KEEP INDEX después de enriquecer:

• restaurant-type: seafood, Mexican/Baja Mexican, tacos, farm-to-table, Japanese/sushi, fine dining si hay demanda e inventario.
• restaurant-best-for: romantic dinner, sunset dinner, date night, family dinner, group dinner, dinner with a view, luxury experience, foodies, si no duplican intención.
• region: Cabo San Lucas, San José del Cabo, Tourist Corridor, Todos Santos, East Cape, La Paz, si tienen inventario y texto propio.

Taxonomías que deben ir a NOINDEX/MERGE:

• términos con 0-2 fichas;
• términos sin descripción o con texto genérico;
• combinaciones casi idénticas;
• páginas que solo muestran grid sin H1/intro/valor editorial.

3.5 Revenue / B2B

/cabo-passport/
/business/
/partners/

Roles:

• /cabo-passport/: producto y conversión.
• /business/: alta/reclamo/list your business.
• /partners/: perks, leads y acuerdos comerciales. TravelDesk fue retirado y no vuelve sin decisión formal.

4. Roadmap definitivo por fases

Fase 0 — Control, seguridad y medición base

Cuándo: semana 0-1
Owner sugerido: Tech SEO + Analytics + Iván
Objetivo: saber qué pasa antes de escalar.

Tareas:

1. Confirmar GSC: - Manual Actions; - Security Issues; - sitemap status; - cobertura/indexación.
2. Confirmar disavow v2: - si fue subido; - propiedad URL-prefix correcta; - fecha/screenshot.
3. Instalar o validar medición: - GA4/Site Kit; - Ahrefs/Web Analytics si aplica; - eventos URL-agnósticos.
4. Aprobar el contrato GA4 v1. Los cinco eventos propuestos son:

passport_cta_click
generate_lead
reservation_click
phone_click
external_website_click

5. Crear antes de emitir los eventos estas custom dimensions v1:

entity_id
vertical
zone
guide_slug
cta_location

Ejemplo mínimo; no emitir hasta que Iván apruebe el contrato y las dimensiones existan:

dataLayer.push({
  event: "reservation_click",
  entity_id: "wic_listing_123",
  vertical: "restaurants",
  zone: "cabo_san_lucas",
  guide_slug: "",
  cta_location: "listing_sticky"
});

Reglas de medición:

• GA4/Site Kit es el sistema para audiencias/conversiones.
• Ahrefs Web Analytics es espejo ligero de tráfico/eventos, no reemplazo de GA4.
• No crear nueva propiedad GA4 por migración; usar la misma propiedad y stream.
• No construir audiencias críticas solo con page_path.
• UTMs internas para Passport/Business deben reemplazarse gradualmente por eventos con entity_id y cta_location, para no ensuciar atribución.
• TravelDesk no forma parte del contrato vigente.

Criterio de éxito:

• Contrato v1 aprobado, custom dimensions creadas y CTAs principales medidos.
• GSC operable.
• No se depende de path para construir audiencias.

Fase 1A — Autoridad orgánica legítima

Cuándo: semana 1-2
Owner sugerido: Iván + Luis/Sales + partnerships
Objetivo: resolver DR0 sin links comprados.

Modelo mental: solo señales externas reales mueven autoridad de dominio/sitio. Publicar más páginas, mejorar diseño o enlazar internamente ayuda a capturar y distribuir demanda, pero no sustituye backlinks legítimos, menciones locales, GBP/citations y relaciones reales con negocios. Este carril corre en paralelo a revenue y contenido; no espera a que el sitio esté “perfecto”.

Tareas:

1. Google Business Profile de WIC, solo si existe elegibilidad presencial verificable.
2. Citations locales/turismo.
3. Tracker de outreach a negocios listados.
4. Badge “Featured on What’s in Cabo”.
5. Emails por segmento: - restaurantes; - hoteles; - golf; - transportation; - tours; - wedding/proposals.
6. Ask legítimo: - enlace a su ficha si quieren mostrar que están en WIC; - sin anchor manipulado; - sin compra de links; - sin intercambio obligatorio de perk por link.
7. PR/editorial local.

Criterio de éxito 60 días:

• 20-40 negocios contactados;
• primeros partners/perks;
• primeros backlinks legítimos;
• primeras impresiones no-marca en GSC.

Fase 1B — Revenue rails

Cuándo: semana 1-2, en paralelo con autoridad
Owner sugerido: Iván + Dev + partnerships
Objetivo: que el tráfico tenga dónde convertir.

1.1 /cabo-passport/

Estado 2026-07-20: ejecutado. Landing 200, index,follow, en sitemap; preview con redirect de un salto; menú, 43 fichas y guías enlazan al destino final con UTM. El form pasó pruebas técnicas y TravelDesk fue retirado.

Debe incluir:

• propuesta de valor;
• beneficios;
• cómo funciona;
• early access o planes;
• CTA;
• tracking;
• FAQ visible;
• relación con perks/partners.

Ya resolvió:

• menú Cabo Passport;
• 43 fichas con enlaces/CTAs hacia cabo-passport;
• CTAs de guías nuevas.

Gate restante: SMTP autenticado y confirmación de recepción real en buzón.

1.2 /business/

Para negocios que quieren aparecer o reclamar ficha.

Debe incluir:

• “List your business on What’s in Cabo”;
• beneficios;
• formulario;
• categorías aceptadas;
• relación con claim listing.

1.3 /partners/

Para perks, Passport, leads y acuerdos comerciales.

Debe incluir:

• qué gana el partner;
• qué tipo de perks buscamos;
• cómo funcionan los leads y su seguimiento;
• formulario;
• UTM/eventos.

Criterio de cierre de la fase:

• Passport y sus CTAs permanecen sanos;
• /business/ y /partners/ dan 200 cuando Iván entregue contenido/destino de leads;
• CTAs medidos;
• ningún CTA Passport importante apunta a 404 o #.

Fase 2 — Limpieza de índice

Cuándo: semana 1-3
Owner sugerido: agente + Tech SEO
Objetivo: dejar de indexar ruido.

Estado 2026-07-20: primera ejecución completada. Se clasificaron 685 términos: 106 KEEP_NOINDEX, 528 NOINDEX y 51 MERGE_CANDIDATE. Se aplicaron 26 de 27 merges LOW con 301; water-activities se conservó para no mezclar tours con facilities de playas. Ninguna taxonomía fue promovida a index sin ledger.

Seguimiento recurrente después de la primera ejecución:

1. Reauditar archives/taxonomías cuando cambie el inventario o aparezca nueva demanda.
2. Mantener cada término dentro de una decisión documentada: - KEEP INDEX; - NOINDEX; - MERGE; - REPLACE WITH GUIDE.
3. Controlar /explore/: - base index solo si se vuelve hub real; - parámetros fuera de sitemap/index; - revisar logs/GSC para detectar rastreo excesivo de facetas.
4. Clasificar taxonomías fuertes: - enriquecer y mantener index si tienen demanda + inventario + contenido; - noindex si son thin; - merge si duplican intención; - replace-with-guide si conviene crear guía editorial.
5. Sacar noindex del sitemap.
6. Sacar del sitemap URLs que no queremos rankear: cart, checkout, shop/placeholders, páginas internas sin valor orgánico.
7. No tocar fichas individuales ni guías aprobadas.

Criterio de éxito:

• reducción de index-bloat;
• sitemap solo con URLs canónicas e indexables;
• sin pérdida de URLs que tengan impresiones útiles.
• taxonomías fuertes convertidas en landings, no grids vacíos.

Fase 3 — Ledger editorial

Cuándo: semana 1-3
Owner sugerido: SEO lead + agente + editorial
Objetivo: que ninguna página nueva se apruebe por intuición.

Cada nodo debe tener:

Regla:

Sin ledger, no se publica.

Fase 4 — Páginas SEO y revenue pages

Cuándo: semana 2-8
Owner sugerido: SEO + editorial + dev
Objetivo: construir solo activos con inventario, demanda y camino de conversión.

4.1 Estado de las páginas P0-P1 al 2026-07-22 UTC

Inventario editorial ejecutado o preparado:

• 17 fichas de golf reescritas; Cabo Real quedó como control y las 18 terminaron 200.
• 33 hoteles reescritos con fuentes oficiales.
• 12 playas enriquecidas; expansión pendiente por lotes.
• 50 restaurantes mejorados en menú/FAQ.
• 10 tours, 6 restaurantes y Cabo Luxury Yachts permanecen draft; cero publicación sin aprobación.

4.2 Build after enrichment

4.3 Backlog / seed first

Fase 4B — Hubs verticales y de zona

Añadida el 2026-07-26. El §3.2 lleva desde el cierre del plan describiendo ocho hubs verticales como arquitectura aprobada, pero ninguna fase los agendaba. Este es el hueco estructural más grande que queda.

4B.1 Estado real medido

De los ocho hubs del §3.2, solo /golf/ existe. Los demás dan 404, y el descubrimiento por vertical vive hoy en /explore/?type=…, que es noindex, follow — es decir, en facetas que el propio §3.4 prohíbe como landing SEO, sin la alternativa indexable construida. Hoy no existe una sola URL capaz de competir por las cabeceras de cada vertical salvo las guías.

4B.2 Qué se puede construir ya

La migración /listing/ liberó los segmentos que estaban ocupados por fichas:

/restaurants/       libre (las fichas usaban /restaurant/ singular)
/things-to-do/      libre
/nightlife/         libre
/tours/             libre (las fichas usaban /tour/ singular)
/hotels/            LIBERADO por la migración
/transportation/    LIBERADO por la migración
/golf/              ya existe y funciona — es el modelo a replicar

4B.3 Bloqueo pendiente de los hubs de zona

La gramática del §3.0 sitúa los hubs regionales en /{zona}/. Esos seis slugs están ocupados por archivos adjuntos (imágenes de portada subidas el 2026-05-15), y como Rank Math tiene attachment_redirect_urls apuntando al home, las seis responden 301 a la portada:

/cabo-san-lucas/  /san-jose-del-cabo/  /tourist-corridor/
/east-cape/       /todos-santos/       /la-paz/

Producción usa hoy /region/{zona}/, en noindex. Liberar los slugs es renombrar el post_name de seis adjuntos —no afecta a la URL del archivo de imagen, que vive en /wp-content/uploads/— pero requiere aprobación porque toca contenido existente.

4B.4 Reglas

Cada hub que se construya pasa el ledger de la Fase 3 y cumple el §3.2: H1 claro, intro editorial única, enlaces a guías y a fichas fuertes, filtros que no generen facetas indexables, CollectionPage/ItemList si aplica, self-canonical y CTA vivo. Sin inventario suficiente no se publica indexable.

Fase 5 — Arquitectura de listings /listing/

Cuándo: EJECUTADA el 2026-07-26 salvo golf. Esta sección se conserva como registro de la decisión y como procedimiento reutilizable para cualquier migración futura de URLs.

Owner sugerido: Tech SEO + dev
Objetivo: comprobar si el target ideal se puede ejecutar sin romper WIC y, si pasa, preparar una migración temprana por lotes sujeta a un nuevo go/no-go antes de que el inventario crezca mucho más.

5.1 Decisión final de namespace

Recomendación:

/listing/{slug}/{id}/

Evidencia externa:

• Visit Los Cabos, DMO oficial del mercado, usa /listing/{slug}/{id}/ para fichas. Ejemplo verificado: https://www.visitloscabos.travel/listing/cocina-de-autor/1283/.
• Visit Florida, Visit Las Vegas, Visit Denver, Go Hawaii, Visit Austin y Destination Toronto usan patrones equivalentes con listing/listings + slug + id.
• Discover Puerto Rico usa /profile/{slug}/{id}.
• Lonely Planet usa /points-of-interest/{slug}/{id}.

Lectura:

Hubs tipados para navegación.
Fichas neutrales con slug + ID.
Editorial/guías aparte.

No /place/ por ahora, porque:

• listing alinea con DMOs/directorios;
• el ID es el mecanismo anti-colisión si dos verticales comparten post_name;
• WIC ya reconoce /listing/... como origen de redirect, pero adoptarlo como canónico exige revertir/controlar ese comportamiento en canary;
• place puede confundirse con el place interno de MyListing.

No /attractions/{slug}/{id}/ por ahora, porque:

• crea un segundo namespace de fichas para entidades que ya deben vivir en /listing/{slug}/{id}/;
• reintroduce clasificación rígida: una misma entidad puede ser beach, landmark, tour stop, nightlife, restaurant o beach club;
• duplica rewrites, redirects, sitemap, schema y smoke tests sin mejorar la semántica;
• la semántica correcta vive en @type, taxonomías, hubs, breadcrumbs e internal links.

Ejemplos de target futuro si el canary pasa:

/listing/sunset-monalisa/1234/        restaurant
/listing/chileno-beach/1290/          beach / place
/listing/cabo-adventures/4300/        tour operator
/listing/hard-rock-los-cabos/2201/    hotel / resort

5.2 Auditoría técnica

Antes de cualquier canary:

1. Revisar rewrite rules.
2. Revisar get_permalink().
3. Revisar _case27_listing_type.
4. Revisar mu-plugins que hardcodean /restaurant/, /beach/, /hotel/, /hotels/, /tour/.
5. Revisar sitemap Rank Math.
6. Revisar schema @id/url.
7. Revisar breadcrumbs.
8. Revisar related listings/internal links.
9. Si existe llms.txt, revisar que no contradiga URLs canónicas; es un complemento opcional, no un requisito de Google Search ni un gate SEO.
10. Auditar colisiones de post_name.
11. Identificar quién emite el redirect actual /listing/ → URL por tipo: core/theme, MyListing, Rank Math, .htaccess o mu-plugin. Sin eso no hay rollback confiable.

5.3 Principio: sí mover, pero mover bien

La postura final no es “esperar años” ni “migrar todo mañana”. La postura final es:

1. Preparar auditoría, mapping y staging ahora.
2. Liberar el gate 11.2 mediante una decisión go/no-go registrada.
3. Ejecutar y validar el canary autorizado.
4. Migrar por lotes solo si pasa y existe un nuevo go/no-go.
5. No crecer a 700/7,000 URLs con una estructura que ya sabemos que queremos cambiar.

Esto protege los dos lados:

• evita una migración masiva a ciegas;
• evita acumular miles de URLs en una estructura que después será más cara de mover;
• permite que las URLs finales empiecen a madurar temprano;
• conserva rollback si MyListing, Rank Math, sitemap, schema, breadcrumbs o redirects se comportan distinto a lo esperado.

Gate 11.2 — autorización previa al canary

Estado 2026-07-26: CERRADO. El gate se liberó con el paquete GATE-11.2-EVIDENCIA-CANARY-LISTING-2026-07-25.md y la migración se ejecutó (ver la actualización de cabecera). Los siete requisitos quedaron cubiertos: 404 Monitor y Redirections activos, mapa 1:1 congelado por lote, cero colisiones, el drift de hoteles disuelto por la propia migración, rollback probado por ficha y aprobación explícita de Iván registrada.

La tabla se conserva como plantilla del procedimiento: cualquier migración futura de URLs —empezando por las 17 fichas de golf— debe volver a cubrir estos mismos puntos antes de ejecutarse.

5.4 Canary

Solo después de liberar el gate 11.2: canary técnico de 5-10 fichas de bajo riesgo. Su función es probar el mecanismo dentro de una muestra autorizada; no habilita una migración mayor por inferencia.

Migrar:

• 1 restaurant;
• 1 beach;
• 1 hotel;
• 1 transportation/tour;
• 1 golf/other.

Antes de tocar URLs en staging o producción:

• backup completo de base de datos y archivos relevantes;
• si wp db export falla en hosting por permisos/tablespaces, usar mysqldump --no-tablespaces;
• registrar lista exacta de URLs viejas/nuevas y rollback.

Cada canary debe pasar:

5.5 Decisión después del canary

5.6 Migración por lotes

Solo si el canary pasa 2-4 semanas y existe un nuevo go/no-go humano para ampliar. La razón para hacerlo después de pasar el canary es precisamente la que marcó Luis y confirmó la investigación: mover 257 URLs bien probadas ahora es más sano que esperar a mover 700, 1,000 o 7,000 después.

Orden:

1. fichas de bajo riesgo;
2. verticales pequeñas;
3. hotels/golf;
4. restaurants al final.

Cada lote debe tener:

• lista vieja/nueva congelada;
• backup antes de ejecutar;
• redirects 301 directos, sin cadenas;
• sitemap regenerado;
• internal links actualizados;
• schema/canonical/og:url consistentes;
• smoke de muestra;
• monitoreo GSC/logs/404s;
• rollback preparado.

Para 257 fichas, incluso si staging, crawl completo y redirect map están automatizados y 100% limpios, la ampliación se ejecuta por lotes controlados. Cualquier propuesta de movimiento completo requiere un gate humano separado y una actualización explícita de este plan. Para 700+ o 7,000, el plan cambia obligatoriamente a bloques todavía más pequeños, sitemaps segmentados y monitoreo más fino.

Fase 6 — Sistema repetible de fichas de golf

Estado 2026-07-22: Cabo Real V3.1 fue aprobado y publicado sobre la URL existente con backup y rollback. Conserva MyListing Reviews/acciones first-party, una escena WebGL, un Google Maps, fotos propias, datos verificados y geometría explícitamente esquemática/no navegable. /golf/ y la guía de golf están live, indexables y en sitemap. La matriz final desktop/móvil pasó sin fallos. Palmilla completó el primer stage privado del skill con HTTP, schema, privacidad, Maps, accesibilidad e interacción en cinco viewports; sigue fuera de producción hasta cerrar sus cuatro gates: derechos de las tres imágenes, teléfono correcto, confirmación visual del pin/entrada física y aprobación visual del release exacto.

Cierre V3.1 ejecutado:

• 6,848 yards se presenta como yardaje total del campo, no como distancia de un hoyo;
• Reviews, Share, Bookmark, Report y Leave a review se conservan mediante MyListing;
• designer context, facilities, inclusiones, pace, dress code y FAQs están visibles con fuentes y omisiones explícitas;
• las tarifas volátiles no se congelan como copy permanente;
• Google CID, coordenadas y dirección fueron reconciliados;
• GolfCourse.address, hasMap, description y breadcrumb schema quedaron corregidos;
• el breadcrumb y un enlace visible conectan Cabo Real con /golf/;
• hay una sola instancia WebGL, un Maps y secciones únicas.

Secuencia obligatoria:

Cabo Real V3.1 aprobado y live
→ skill wic-golf-listing separado y auditado
→ package investigado y congelado para un solo campo
→ preview privado ligado al hash exacto del release
→ QA automático + revisión visual humana
→ aprobación externa del release visto
→ backup + activación atómica + smoke/rollback automático
→ expansión uno por uno

Separación de responsabilidades:

• el componente WordPress presenta hero, facts, galería, ratings, Maps, 3D, planificación y accesibilidad;
• MyListing conserva Reviews, Share, Bookmark, Report y acciones first-party;
• el skill consume un package investigado y congelado; no investiga y publica en la misma ejecución;
• hechos editoriales, datos operativos, media y geometría viven en contratos separados.

Contrato mínimo de wic-golf-listing:

• target: post ID, slug, update-existing por defecto y schemaVersion;
• configuraciones, hoyos, par, yardaje, diseñador, acceso y base de yardaje; rating/slope sólo cuando el contrato los incorpore y una fuente consistente los sostenga;
• políticas/tarifas con fuente y checkedAt como fecha UTC YYYY-MM-DD;
• dirección, coordenadas y pin verificado;
• facilities y FAQs visibles;
• media con procedencia, permiso, ALT y pertenencia al campo;
• geometry.mode: none, official-schematic o verified-gis, con fuente/licencia; el runtime compartido v1.0.0 sólo permite activar none hasta aprobar el adaptador común de geometría;
• backup antes de write, CAS transaccional, apply idempotente, readback, purge, smoke, Playwright y rollback automático;
• aprobación externa separada, ligada al hash exacto que se revisó en preview;
• procedencia de media con attachment parent, mimeType allowlisted, dimensiones, bytes, SHA-256, URL fuente y estado de derechos; el MIME debe coincidir tanto con post_mime_type como con la detección binaria del archivo en WordPress;
• allowlist de URLs/Google y bloqueo SSRF para toda comprobación de red.

Gates duros:

• nunca presentar geometría esquemática como GPS exacta;
• nunca reutilizar geometría, fotos o datos de Cabo Real en otro campo;
• modelar campos de 9/18/27 hoyos y combinaciones reales;
• un solo WebGL y un solo Maps por ficha;
• no publicar aggregateRating sin reseñas first-party verificables;
• no volver a tocar Cabo Real sin backup, CAS y QA proporcional;
• la migración /listing/ sigue siendo un gate independiente y no se mezcla con el piloto del skill.

7. Reglas SEO para cualquier página nueva

Toda página nueva debe pasar:

1. keyword o razón de negocio;
2. inventario real;
3. contenido único;
4. imagen hero;
5. width/height/srcset/alt;
6. author/editorial team;
7. canonical self;
8. sitemap solo si indexable;
9. ItemList si es best-of;
10. sources visibles;
11. CTA vivo;
12. smoke;
13. GSC/Rank Tracker cuando aplique. llms.txt, si existe, se trata fuera del gate como complemento opcional.

Reglas duras:

• No aggregateRating falso.
• No importar reviews de Google/TripAdvisor como propias.
• No FAQPage por default. Google dejó de mostrar FAQ rich results en mayo de 2026 y retiró su documentación en junio de 2026. Las FAQs visibles siguen siendo útiles para usuarios y cobertura temática; el markup existente puede mantenerse temporalmente si es válido, pero no se presenta como oportunidad de rich result.
• No páginas de faceta sin editorial.
• No páginas con <6 fichas salvo razón BOFU explícita.
• No links comprados.
• No publicar si CTA principal apunta a 404.
• No crear archivos, “chunks” o páginas como hacks AEO/GEO. Google recomienda el SEO técnico habitual y contenido propio, experto, útil y no genérico para sus funciones generativas.
• llms.txt es opcional para consumidores que decidan usarlo; Google Search declara que no lo necesita ni lo usa como señal especial de ranking o aparición.
• No prometer rankings, indexación, AI Overviews ni citas de asistentes.

Schema por tipo:

• Ficha restaurante: Restaurant limpio con address, geo, url, image, telephone, servesCuisine, priceRange, hasMenu/acceptsReservations si existen.
• Hotel: Hotel o LodgingBusiness, no Restaurant.
• Playa/atracción: TouristAttraction o tipo más específico si aplica.
• Guía editorial: Article/WebPage + BreadcrumbList; ItemList solo si hay lista/ranking visible.
• Ratings externos: pueden mostrarse como badge atribuido, pero no como Review/AggregateRating propio de WIC.
• Una sola fuente por entidad: evitar que Rank Math, MyListing y mu-plugin emitan duplicados contradictorios.

Core Web Vitals objetivo al percentil 75 cuando exista field data:

LCP <= 2.5 s
INP <= 200 ms
CLS <= 0.1

Fuentes primarias vigentes:

• Google Search generative AI guidance: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
• Google Search documentation updates: https://developers.google.com/search/updates
• Core Web Vitals: https://developers.google.com/search/docs/appearance/core-web-vitals

8. Qué documentos quedan como fuente

Fuente operativa única

PLAN-SEO-FINAL-WIC-2026-06-30.md

Este .md es el plan canónico operativo. Es el archivo que manda para SEO, arquitectura, contenidos, dev, migraciones y coordinación con Luis/Claude/Codex.

El HTML es una exportación/resumen visual para seguimiento. Si el HTML y este .md se contradicen, manda este .md. Al 2026-07-26 el HTML no refleja la migración /listing/; regenerarlo antes de compartirlo con nadie.

Anexos operativos de este plan

• GATE-11.2-EVIDENCIA-CANARY-LISTING-2026-07-25.md — evidencia con la que se liberó el gate y se autorizó la migración.
• EXECUTION-LOG-CODEX.md — bitácora por tarea: comandos, hashes, verificación y rollback de cada lote.
• PLAN-EJECUCION-FINAL-WIC-2026-07-12.md — runbook que opera este plan. Si contradice a este documento, manda este documento.

Históricos / insumos

Los siguientes documentos son históricos o insumos, no roadmap operativo si contradicen este plan:

• REPORTE-MAESTRO-LUIS-CODEX-CLAUDE-SEO-2026-06-26.*
• PLAN-SEO-EXPLICADO-A-DETALLE-2026-06-30.md
• REPORTE-LUIS-COLOR-CODED-2026-06-26.*
• documentos de Luis en luis-skills-v2-mejorada/
• DOCX/Numbers de propuesta externa.

Skills operativos

Se mantienen como herramientas:

• wic-restaurant-listing v1.0.11: fichas de restaurantes desde package investigado.
• wic-activity-listing v1.0.1: tours/actividades desde package investigado.
• wic-vertical-guide v0.7.0: guías/best-of/pillars con gates.
• wic-golf-listing v1.0.0: fichas de golf desde package investigado, preview privado y aprobación del release exacto; no reutiliza geometría/media entre campos ni mezcla la migración /listing/.
• SEO skills internos: auditoría, sitemap, programmatic, technical y page.

Los skills WIC de .claude/skills/ son la fuente operativa para este proyecto y no sustituyen las reglas de datos, medios, SEO, aprobación y publicación de este plan.

La investigación y la escritura productiva permanecen separadas: un proceso read-only produce un package con fuentes; el skill valida y aplica ese package. Ningún skill garantiza posicionamiento rápido.

9. Qué NO hacer

No hacer:

1. migrar URLs sin pre-flight de enlaces, backup, mapa congelado, verificación y rollback — aplica ahora a las 17 fichas de golf, que son las únicas que quedan;
2. mover guías actuales a /guides/;
3. publicar guías nuevas en raíz por inercia si ya se adoptó /guides/{slug}/ como estándar;
4. NO crear /attractions/{slug}/{id}/ como segundo namespace de fichas;
5. NO crear /beaches/ top-level si el hub aprobado es /things-to-do/beaches/;
6. construir directorio programático completo;
7. publicar 42 páginas de restaurants por batch;
8. publicar 27 páginas de tours;
9. publicar nightlife/weddings/bachelorette sin inventario;
10. indexar taxonomías thin;
11. comprar links;
12. usar PBNs;
13. manipular anchors;
14. emitir ratings falsos;
15. medir éxito por páginas publicadas.

10. Métrica norte

Para los próximos 60 días, el éxito no es “cuántas páginas publicamos”.

La métrica norte es:

partners firmados
perks activos
eventos medidos
backlinks legítimos
primeras impresiones no-marca
leads Passport / Business / Partners / reservas externas

El SEO orgánico madurará en meses. El ingreso temprano debe venir de venta directa, partners, Passport y leads medidos; TravelDesk no forma parte del sistema vigente.

11. Próxima acción recomendada

Prioridad inmediata:

1. presentar el preview privado exacto de Palmilla cuando su package pase todos los gates de staging;
2. resolver antes de activarlo: derechos de las fotos, conflicto de teléfono y revisión visual del pin/entrada;
3. recibir aprobación humana ligada al hash exacto visto;
4. activar sólo ese campo con backup, CAS, smoke y rollback automático;
5. observar la ficha antes de preparar el siguiente campo;
6. repetir investigación → package → preview → aprobación → activación uno por uno;
7. mantener geometry.mode=none cuando no exista geometría verificable/licenciada.

Carriles paralelos:

1. autoridad orgánica legítima: outreach, partners, PR local y citations; GBP solo si existe elegibilidad presencial;
2. cerrar SMTP real de Passport;
3. aprobar contrato GA4 v1 y crear custom dimensions antes de emitir eventos;
4. definir contenido/destino de leads para /business/ y /partners/;
5. revisar las seis guías follow,noindex y los flip-packs de tours/restaurantes/yacht;
6. continuar enriquecimiento de beaches antes de /things-to-do/beaches/;
7. construir los hubs verticales — ver la Fase 4B;
8. coordinar con el equipo de golf la migración de sus 17 fichas y el arreglo de su breadcrumb.

Este orden refleja lo ya ejecutado y evita volver a presentar Passport, Guides, la primera higiene de índice o la migración /listing/ como trabajo por iniciar.

← Volver al Centro de investigaciones