Nivel del sitio · L2

El Índice de sección: el catálogo que explica una rama y lista sus hijos

El nivel 2 es el índice de una sección: la página que dice de qué va una rama del sitio y muestra todos sus hijos como tarjetas. /modulos, /productos, /servicios y /blog son todos L2. Su trabajo es orientar y mandar a la ficha correcta, no agotar un tema.

Esta ficha documenta el L2 a fondo: qué problema resuelve (orientar + distribuir a las fichas + anclar el SEO de la categoría), de qué cinco piezas se compone (encabezado de sección con migas, intro de contexto, rejilla de hijos data-driven, filtros o destacados opcionales, y cierre), qué tipos de índice existen (grid de tarjetas, con filtros, blog, lista densa, editorial, mínimo), cómo se comporta en el teléfono (grid 4→2→1, filtros en drawer, migas de un nivel, cards táctiles) y cómo se construye iterando una colección con getCollection.

Con dos rasgos que lo distinguen de la home (L1) y de la ficha (L3). Frente al L1: el índice SÍ lleva migas de pan —de un nivel, Inicio › Sección—, porque tiene padre. Frente al L3: el índice no agota un tema, lo reparte —cada card es una entrada a su ficha, no la ficha entera—. Es la página pilar de la sección: concentra los enlaces de sus hijos y reparte autoridad hacia ellos (hub-and-spoke), emitiendo una sola ItemList (regla B3), nunca un schema por tarjeta.

Definición

¿Qué es el nivel L2 · Índice de sección?

La página que lista los hijos de una rama del sitio y explica de qué va: /modulos, /productos, /servicios, /blog. Cuelga directamente de la home (L1) y es padre de las fichas (L3). Su trabajo no es presentar el negocio entero (eso es la home) ni agotar un tema (eso es la ficha): es orientar dentro de una sección y mandar a la ficha correcta.

El L2 es el índice de una sección: la antesala de las fichas. Cada rama del sitio tiene el suyo —productos, servicios, módulos, blog, e incluso esta serie de niveles—. El visitante llega aquí desde la home o el menú, entiende qué incluye la sección y elige a qué ficha entrar. Es un mapa de una rama, no del sitio entero.

En esta plantilla vive en src/pages/<seccion>/index.astro y se arma iterando una colección (getCollection) o una lista de site.ts: una card por hijo, generada con .map(). Lleva migas de pan de un nivel (Inicio › Sección) porque tiene padre, y es la página pilar de la sección para el SEO —concentra y reparte la autoridad de sus hijos—.

Función e importancia

¿Para qué sirve?

Tres trabajos: orientar (decir qué hay en la sección y cómo navegarla), distribuir (mandar a la ficha correcta con enlaces de anchor text real) y anclar el SEO de la categoría (rankear por términos amplios y repartir autoridad a los hijos vía hub-and-spoke). Un buen índice baja rebotes y sube la tasa de clic hacia las fichas.

La función primaria del índice es orientar: convierte una sección en un mapa escaneable. El visitante entiende de qué va la rama y encuentra el hijo correcto sin perderse. La secundaria es distribuir: cada card enlaza a su ficha con anchor text real (el nombre del hijo), de modo que tanto la persona como el crawler saben a dónde lleva cada enlace.

La terciaria es de SEO: el índice es la página pilar de la sección. Rankea por términos de categoría (más amplios que los de una ficha) y, vía hub-and-spoke, concentra los enlaces internos de sus hijos y les reparte autoridad. Su schema natural es ItemList/CollectionPage, emitido una sola vez por el grid padre (regla B3) —nunca una vez por tarjeta—.

Orienta — dice «esto es lo que hay aquí»

El índice es la antesala de las fichas: su trabajo es que el visitante entienda de qué va la sección y encuentre el hijo correcto sin adivinar. A diferencia de la home (que reparte entre secciones) o de la ficha (que agota un tema), el L2 ordena una rama: presenta el contexto, muestra todos los hijos como tarjetas escaneables y deja que el visitante elija. Un índice claro reduce los rebotes —el visitante no se pierde entre opciones— y mejora la tasa de clic hacia las fichas.

Distribuye — manda a la ficha correcta

El índice convierte una sección entera en un mapa navegable. Cada tarjeta enlaza a su ficha L3 con anchor text real (el nombre del hijo, no «ver más»), así el visitante y el buscador entienden a dónde lleva cada enlace. Es data-driven: la rejilla se genera desde una colección o una lista (SSoT), de modo que el índice nunca se desincroniza del contenido real —si agregas un producto, aparece en su índice sin tocar la página—.

Ancla SEO de categoría — rankea por términos amplios

Mientras la ficha L3 rankea por términos específicos («casco de seguridad marca X»), el índice L2 rankea por términos de categoría («cascos de seguridad», «servicios de consultoría»). Es la página pilar de la sección: concentra los enlaces internos de sus hijos y reparte autoridad hacia ellos (patrón hub-and-spoke). Su schema típico es ItemList o CollectionPage, emitido una sola vez por el grid padre (regla B3), nunca por cada card.

Anatomía

¿Qué lleva por dentro?

Cinco piezas: encabezado de sección con migas de un nivel, intro de contexto (SectionHeading duo), rejilla de hijos data-driven (CategoryCard/ProductCard), filtros u destacados opcionales para catálogos grandes, y cierre. El corazón es la rejilla: una card por hijo, generada con .map() sobre una colección.

El índice es una composición sobria: encabeza, contextualiza, lista y cierra. La pieza 1 (encabezado + migas) ubica al visitante. La 2 (intro) da contexto. La 3 (rejilla) es el corazón —los hijos como cards data-driven, el mismo componente que el resto del sitio—. La 4 (filtros/destacados) es opcional y escala con el tamaño del catálogo. La 5 (cierre) reparte o convierte.

Todo lo importante es data-driven: la rejilla se genera desde getCollection() o una lista de site.ts, así que el índice nunca queda viejo. Esa es la diferencia entre un índice que se mantiene solo y uno que hay que editar a mano cada vez que cambia el catálogo. El índice compone; no hardcodea.

  1. Encabezado de sección — qué es esta rama + migas

    El hero (o un SectionHeading fuerte) que nombra la sección y dice de qué va en una frase. A diferencia de la home, aquí SÍ van migas de pan de un nivel (Inicio › Sección), porque el índice tiene padre: la home. El h1 lleva el nombre de la sección con su keyword (p. ej. «Productos», «Servicios», «Módulos del sitio»).

    SSoT: src/pages/<seccion>/index.astro → <Hero> · breadcrumbs={[{ label: "Sección" }]} · h1 = nombre de la sección

  2. Intro — el contexto de la sección

    Un SectionHeading layout="duo" que explica qué incluye la sección y cómo está organizada, antes de la rejilla. Orienta: «esto es lo que hay aquí y cómo navegarlo». Mantiene la jerarquía (h2) y da contexto a personas y buscadores antes de la lista de hijos.

    SSoT: src/components/SectionHeading.astro layout="duo" · h2 + 2 párrafos de contexto

  3. Rejilla de hijos (CategoryCard / ProductCard) — el corazón

    La cuadrícula de tarjetas que lista los hijos de la sección: cada producto, servicio, módulo o artículo como una card uniforme con foto, título H3 y CTA. Es data-driven —se genera con un .map() sobre una colección (getCollection) o una lista de site.ts—, así que agregar un hijo lo pinta sin tocar la página. La regla del sitio: el mismo card para todas las secciones, cero diseño duplicado.

    SSoT: CategoryCard.astro / ProductCard.astro · grid .showcase 1→2→4 · getCollection() o SSoT

  4. Filtros / orden o destacados (opcional) — para catálogos grandes

    Cuando la sección tiene muchos hijos, una barra de filtros (categoría, precio, etiqueta) u orden ayuda a encontrar. Cuando tiene pocos, se omite. Alternativamente, un bloque de destacados (CategoryDetail) amplía la entrada más importante. La regla: no añadir filtros si caben todas las tarjetas de un vistazo —añaden fricción sin valor—.

    SSoT: Opcional · filtros/facetas para catálogos amplios · CategoryDetail para destacar

  5. Cierre — el siguiente paso

    Una franja final que reparte hacia otras secciones (SectionMenu) o pide una acción (CTABanner). En un índice de catálogo suele ser un CTA contextual («¿no encuentras lo que buscas? cotiza»). Seguido del footer, que aparece en todas las páginas. El número de WhatsApp se arma con waUrl() —nunca hardcodeado—.

    SSoT: SectionMenu.astro o CTABanner.astro (PRESET_CATEGORIA) · waUrl(WA_MESSAGES.x)

Otros diseños y aplicaciones

Tipos de índice

Seis formas de listar una sección: grid de tarjetas (catálogo clásico, la de esta plantilla), con filtros/facetas (e-commerce), blog index (feed + categorías + tags), lista densa (directorio), editorial (destacado + grid) y mínimo (pocas entradas, cards grandes). Todos son L2 —orientan y reparten— pero cambian la densidad y la forma de encontrar.

El nivel no cambia, la densidad sí. Un catálogo de 8 servicios pide un grid limpio; uno de 200 productos pide filtros; un blog pide un feed cronológico con categorías; un directorio pide una lista densa. Reconocer el tipo correcto evita dos errores opuestos: filtros sobrantes en una sección chica, o una rejilla plana imposible de navegar en una grande.

Cada tipo reordena las mismas piezas: encabezado, contexto, lista de hijos, controles de navegación. La plantilla parte del grid de tarjetas porque es el caso central (productos, servicios, módulos); los demás se arman recomponiendo los mismos componentes y escalando la complejidad con el tamaño real del catálogo.

  • SecciónInicio › Sección

    1 · Grid de tarjetas — catálogo clásico (REAL · /modulos, /productos)

    Catálogo · Servicios · Módulos · Casos

    La cara natural del índice en esta plantilla: encabezado de sección + rejilla de cards (CategoryCard/ProductCard) 1→2→4 por fila, data-driven desde una colección o lista. Es /modulos, /productos y /servicios hoy. Aplica a cualquier sección con hijos visuales y un número manejable de entradas. El visitante escanea, elige y entra a la ficha.

  • 2 · Índice con filtros / facetas — e-commerce

    Tienda · Catálogo amplio · Muchos hijos

    Para catálogos grandes: barra lateral o superior de filtros (categoría, precio, marca, disponibilidad) + orden (relevancia, precio, novedad) + el grid de productos. Los filtros actualizan la rejilla (idealmente sin recargar). Aplica cuando hay decenas o cientos de hijos y encontrar requiere acotar. En móvil los filtros se pliegan en un drawer.

  • GuíasNovedades

    3 · Blog index — feed + categorías + tags (REAL · /blog)

    Blog · Medio · Knowledge base

    El índice editorial: feed cronológico de artículos (el más reciente arriba) + navegación por categoría y por tag. Es /blog hoy, con sus rutas hijas /blog/categoria/<x> y /blog/tag/<y> (que son a su vez índices filtrados). El protagonista es la frescura: lo último primero. El SEO vive en el volumen de fichas L3 (artículos) que cuelgan de aquí.

  • 4 · Lista densa — directorio

    Directorio · Listado largo · Poca foto

    Cuando hay muchos hijos y la foto importa poco: una lista compacta (nombre + una línea + enlace), agrupada por inicial o categoría. Prioriza densidad y escaneo rápido sobre impacto visual. Aplica a directorios de cobertura, glosarios, listados de sucursales o cualquier índice donde el visitante busca un nombre concreto.

  • Destacado

    5 · Índice editorial — destacado + grid

    Sección con jerarquía · Lanzamiento · Campaña

    Un hijo destacado en grande arriba (CategoryDetail o card hero) + la rejilla del resto debajo. Sirve cuando una entrada de la sección importa más que las demás (producto estrella, servicio insignia, artículo pilar). Da jerarquía sin sacar al destacado de su sección. La regla del sitio (sin zig-zag) se mantiene en el grid de abajo.

  • 6 · Índice mínimo — pocas entradas, cards grandes

    Sección pequeña · 2-4 hijos · Servicios premium

    Cuando la sección tiene pocos hijos (2-4), cards grandes a 1-2 columnas con más texto y foto. No fuerza una rejilla de 4 que quedaría vacía. Aplica a secciones de servicios premium o líneas de producto cortas, donde cada hijo merece espacio. La estructura es la misma; cambia la densidad.

Responsive y móvil

El índice, en el teléfono

Cuatro patrones reales: rejilla de hijos 4→2→1 mobile-first, filtros que colapsan en un drawer, migas de un nivel que truncan labels largos antes de romper a dos líneas, y cards + paginación táctiles. El reto del índice en móvil es listar muchos hijos sin que el visitante se pierda al hacer scroll.

El índice en móvil es, sobre todo, una columna larga de tarjetas. El grid arranca en una columna y crece con ancho —el mismo .showcase del catálogo, no diseño nuevo—. Las cards se tocan cómodo (44 px) y la paginación, si existe, también. El visitante recorre una columna clara en lugar de una rejilla apretada.

El detalle propio del L2 son los filtros: en escritorio viven en una barra visible; en el teléfono ocupan demasiado, así que se pliegan tras un botón «Filtrar» que abre un drawer o un <details> nativo. El grid recupera el ancho completo y el visitante filtra solo cuando lo necesita. Las migas, de un nivel, casi nunca desbordan; en lo más estrecho truncan con ellipsis.

1 · Rejilla de hijos 4 → 2 → 1

El grid del índice (.showcase) arranca en una columna y crece con min-width (2 en tablet, 4 en escritorio). Es el mismo grid del catálogo —el índice no inventa diseño—. En móvil, una columna cómoda de escanear en lugar de cuatro tarjetas apretadas.

CSS · rejilla mobile-first 
/* MÓVIL · REJILLA DE HIJOS 4 → 2 → 1 (mobile-first)
   El grid del índice arranca en UNA columna y crece con min-width.
   Mismo .showcase del catálogo: el índice no inventa diseño propio. */

.showcase { display: grid; grid-template-columns: 1fr; gap: var(--sp-5); }
@media (min-width: 640px)  { .showcase { grid-template-columns: repeat(2, 1fr); } }
@media (min-width: 1024px) { .showcase { grid-template-columns: repeat(4, 1fr); } }

2 · Filtros que colapsan en drawer

En escritorio los filtros viven en una barra lateral; en el teléfono se pliegan tras un botón «Filtrar» que abre un panel (drawer) o un <details> nativo. El grid recupera el ancho completo y el visitante filtra solo cuando lo necesita. El botón cumple el área táctil de 44 px.

CSS · filtros en drawer móvil 
/* MÓVIL · FILTROS QUE COLAPSAN EN DRAWER
   En escritorio los filtros viven en una barra lateral visible. En el
   teléfono ocupan demasiado: se pliegan tras un botón «Filtrar» que
   abre un panel (drawer) o un <details> nativo. El grid recupera el
   ancho completo y el visitante filtra solo cuando lo necesita. */

.filtros { display: block; }                 /* barra lateral en desktop */

@media (max-width: 768px) {
  .filtros { position: fixed; inset: 0; transform: translateX(-100%); }
  .filtros[data-open="true"] { transform: translateX(0); }
  .filtros__toggle { display: inline-flex; min-height: 44px; }  /* botón abrir */
}

3 · Migas de un nivel, sin desbordar

El índice solo lleva un salto (Inicio › Sección), así que casi nunca desborda. En pantallas muy angostas se truncan los labels con text-overflow: ellipsis en lugar de romper a dos líneas. El visitante conserva el «volver al inicio» en una sola línea.

CSS · migas de un nivel con ellipsis 
/* MÓVIL · MIGAS DE UN NIVEL (Inicio › Sección)
   El índice solo lleva un salto, así que casi nunca desborda. Aun así,
   en pantallas muy angostas se truncan los labels largos con ellipsis
   en lugar de romper a dos líneas. */

.crumbs { display: flex; gap: .35rem; font-size: var(--text-xs); white-space: nowrap; }
.crumbs a, .crumbs span {
  overflow: hidden; text-overflow: ellipsis; max-width: 16ch;
}

4 · Cards y paginación táctiles

Cada card del índice y cada control de paginación crecen al área táctil de 44 px (Apple HIG · WCAG SC 2.5.5), con realce de toque al tap. En un índice largo, la paginación cómoda evita el «scroll infinito» que pierde la posición del visitante.

CSS · card y paginación táctiles 
/* MÓVIL · CARD Y PAGINACIÓN TÁCTILES
   Las cards del índice y los controles de paginación crecen al área
   táctil de 44 px. El grid completo se toca cómodo con el pulgar. */

@media (max-width: 1024px) {
  .ccard, .pager a, .pager button {
    min-height: 44px;
    -webkit-tap-highlight-color: rgba(91, 61, 245, .15);
  }
}

Posición en la jerarquía

¿Dónde va en el sitio?

Un nivel bajo la home: cada índice cuelga directamente del L1 y es padre de las fichas L3 de su sección. Lleva migas de un nivel (Inicio › Sección). Es el nodo intermedio del árbol: recibe tráfico de la home y del menú, y lo reparte hacia las fichas. Su URL es /<seccion> (sin barra final, regla del sitio).

El L2 ocupa el primer nivel bajo la raíz: /productos, /servicios, /modulos, /blog, /niveles. Cada uno es hijo directo de la home y padre de sus fichas L3. Por eso lleva migas de un nivel (Inicio › Sección) y aparece en el menú principal del header como entrada con su dropdown de hijos —el menú y el índice se alimentan de la misma fuente (NAV/colección)—.

En el flujo del visitante, el índice es la parada intermedia: llega desde la home o el menú, se orienta, y baja a la ficha. En el flujo de SEO, es la página pilar: recibe enlaces de sus hijos (cada ficha enlaza «volver a la sección» vía migas) y reparte autoridad hacia ellos. Quitar un índice rompería el puente entre la home y las fichas.

Capa técnica

Cómo está construido

Vive en src/pages/<seccion>/index.astro e itera una colección (getCollection) o una lista de site.ts para pintar una card por hijo. Lleva pageType='page' + breadcrumbs de un nivel. Emite ItemList/CollectionPage una sola vez desde el grid padre (regla B3); las cards NO emiten schema. Cero hijos hardcodeados.

La arquitectura del L2 es iteración data-driven: el índice obtiene sus hijos de una fuente (getCollection para productos/servicios/blog, o una lista de site.ts como MODULOS/NIVELES) y los pinta con .map(). No hay tarjetas escritas a mano —agregar un hijo a la colección lo pinta en su índice sin tocar el .astro—. Esa disciplina mantiene el índice sincronizado con el contenido real.

Dos detalles técnicos del nivel: las migas de un nivel (el índice tiene padre, así que declara su sección y Breadcrumbs antepone «Inicio») y el schema de lista (el índice es el lugar del ItemList; el emisor es único —el helper del grid o buildSchema—, nunca una card por su cuenta). La receta A muestra cómo se itera la colección; la B, cómo se emite la lista sin duplicar el grafo.

A · src/pages/productos/index.astro — iterar la colección 
---
// src/pages/productos/index.astro — un índice L2 data-driven.
// El índice itera una colección y pinta una card por hijo. NO escribe
// los hijos a mano: getCollection() es la fuente. Migas de un nivel.
import PageLayout from '@layouts/PageLayout.astro'
import SectionHeading from '@components/SectionHeading.astro'
import ProductCard from '@components/ProductCard.astro'
import { getCollection } from 'astro:content'

const productos = (await getCollection('productos'))
  .filter((p) => !p.data.noindex)
  .sort((a, b) => (a.data.order ?? 0) - (b.data.order ?? 0))
---

{/* Migas de UN nivel: el índice tiene padre (la home). */}
<PageLayout title="Productos — catálogo" description="..."
  pageType="page" breadcrumbs={[{ label: 'Productos' }]}>

  <SectionHeading layout="duo" eyebrow="Catálogo" title="Productos"
    desc="Lo que ofrecemos, por categoría." body={["...", "..."]} />

  <div class="showcase">
    {productos.map((p, i) => (
      <ProductCard
        title={p.data.title}
        href={`/productos/${p.id}`}        {/* enlace a la ficha L3 */}
        image={p.data.image}
        description={p.data.excerpt}
        index={i}
      />
    ))}
  </div>
</PageLayout>
B · ItemList del índice — emisor único (regla B3) 
---
// El índice emite ItemList (la lista de hijos) UNA sola vez.
// Las cards NO emiten schema (regla B3 — un emisor por página).
// El Product/Service individual vive solo en la ficha L3.
import { directorySchema } from '@lib/seo'   // helper del grid padre

// directorySchema arma un ItemList con los hijos del índice:
const itemList = directorySchema(
  productos.map((p) => ({ name: p.data.title, url: `/productos/${p.id}` }))
)
// itemList = { '@type': 'ItemList', itemListElement: [{ '@type':'ListItem', position, url, name }, ...] }
// buildSchema() lo compone en el @graph base; la página NO mete <script> a mano.
---

{/* En las cards NO pongas Product JSON-LD: */}
{/* el ItemList del índice + el Product de la ficha L3 bastan. */}

Buenas prácticas

Qué hacer y qué evitar

Siete hábitos que mantienen el índice como una página pilar viva, navegable y bien enlazada; siete errores que la convierten en una lista vieja, incoherente o que no enseña a dónde lleva nada. El índice es el puente entre la home y las fichas: si falla, las fichas reciben menos tráfico y peor enlazado.

La diferencia entre un índice que reparte y uno que estanca es disciplinaria: nombre de sección como h1, rejilla data-driven, card reusada, migas de un nivel, anchor text real, ItemList único y filtros proporcionales. Cada regla viene de un error real: hijos hardcodeados que se quedan viejos, una card distinta por sección, migas ausentes, «ver más» por todos lados, el detalle entero en la card, un schema por tarjeta, filtros de sobra.

Los sí son hábitos de SSoT + jerarquía + SEO de categoría. Los no son atajos que parecen rápidos (hardcodear cuatro productos, copiar «ver más») pero rompen el trabajo del índice: orientar y repartir, sincronizado con el contenido. Léelos en pares.

Sí

  • Pon el nombre de la sección como h1, con su keyword de categoría. El h1 del índice es el término amplio por el que rankea la página pilar: «Productos», «Servicios de consultoría», «Módulos del sitio». Las cards de abajo son h3; el contexto intermedio, h2. Un solo h1 por página, siempre.
  • Genera la rejilla con .map() sobre una colección o lista (data-driven). El índice NO escribe sus hijos a mano: itera getCollection('productos') o una lista de site.ts. Agregar un hijo lo pinta solo; cambiar el orden se hace en la fuente. Cero tarjetas hardcodeadas que se queden viejas.
  • Reusa el mismo card que el resto del sitio (CategoryCard / ProductCard). El índice no inventa un diseño de tarjeta propio: usa el componente del catálogo. Así productos, servicios, módulos y blog se ven y se navegan igual, y mantener una card mejora todas las secciones a la vez.
  • Lleva migas de pan de un nivel (Inicio › Sección). El índice tiene padre —la home—, así que muestra el rastro. El componente Breadcrumbs antepone «Inicio»; la página solo declara su sección. Es la diferencia con el L1, que no lleva migas por ser la raíz.
  • Usa anchor text real en cada card: el nombre del hijo, no «ver más». El texto del enlace es lo que leen el visitante y el crawler. «Consultoría de desarrollo web» enseña; «ver más» no enseña nada y diluye el SEO. Cada card enlaza a su ficha con su nombre propio.
  • Emite ItemList / CollectionPage una sola vez, desde el grid padre. El índice es el lugar del ItemList (la lista de hijos); las cards NO emiten schema propio (regla B3). El emisor es único —el helper del grid o buildSchema—, así Google ve una sola lista bien formada, no una por tarjeta.
  • Añade filtros solo cuando la sección los necesita. Para 6 servicios, una rejilla basta. Para 200 productos, filtros por categoría/precio ayudan. La regla: si todas las tarjetas caben de un vistazo, los filtros añaden fricción sin valor. Escala la complejidad con el tamaño real del catálogo.

No

  • NO hardcodees los hijos de la sección en el .astro. Escribir cada producto a mano en index.astro garantiza que el índice se quede viejo en cuanto cambie el catálogo. La rejilla se genera desde la colección o la lista (SSoT); el día que agregas un hijo, aparece solo. Hardcodear es deuda asegurada.
  • NO inventes un diseño de card distinto por sección. Si productos usa una tarjeta y servicios otra, el sitio se ve cosido a parches y mantienes dos componentes. Reusa CategoryCard / ProductCard; la coherencia visual entre secciones es parte de la calidad percibida del sitio.
  • NO omitas las migas de pan en el índice. El L2 tiene padre (la home): sin migas, el visitante pierde el «dónde estoy» y el «volver». Las migas de un nivel (Inicio › Sección) son obligatorias en todo lo que no sea la raíz. Solo el L1 va sin ellas.
  • NO uses «ver más» / «click aquí» como texto de las cards. Es anchor text muerto: no dice a dónde lleva, penaliza el SEO y obliga al visitante a leer alrededor para entender. Cada enlace lleva el nombre real del destino. Un índice lleno de «ver más» es un índice que no enseña.
  • NO metas el detalle completo de cada hijo en el índice. La tentación de explicar cada producto a fondo en su card convierte el índice en una página infinita y le roba el trabajo a la ficha L3. El índice presenta (foto + título + una línea + enlace); el detalle vive un nivel más abajo.
  • NO emitas un schema por cada card del grid. Veinte Product/Service en el markup del índice ensucian el grafo y confunden a Google. El índice emite UNA ItemList (la lista de hijos); el Product/Service individual vive solo en la ficha L3 (regla B3, un emisor por página).
  • NO satures el índice de filtros que no se usan. Filtros por marca, precio, color, fecha y rating en una sección de 8 productos son ruido: ocupan espacio y no ayudan. La complejidad de navegación debe ser proporcional al tamaño del catálogo, no al deseo de parecer «completo».

Preguntas frecuentes · el nivel L2

¿El índice de sección lleva migas de pan?

Sí, de un nivel (Inicio › Sección). El índice tiene padre —la home—, así que muestra el rastro; el componente Breadcrumbs antepone «Inicio» y la página solo declara su sección. La única página sin migas es el L1 (la raíz). El L2 lleva uno, el L3 dos y el L4 tres.

¿Cuál debe ser el H1 de un índice?

El nombre de la sección con su keyword de categoría —el término amplio por el que rankea la página pilar— (p. ej. «Productos», «Servicios de consultoría»). Las tarjetas de abajo son H3 y el contexto intermedio H2 (WCAG 2.2 SC 1.3.1, Info and Relationships). El índice rankea por el término de categoría; la ficha L3, por el específico. No repitas en la ficha el H1 del índice.

¿El índice emite un schema por cada tarjeta?

No. El índice emite una sola ItemList (o CollectionPage) con la lista de hijos, desde el grid padre. Las tarjetas NO emiten schema propio; el Product/Service individual vive solo en la ficha L3 (regla B3 — un único emisor por página). Veinte schemas en un índice ensucian el grafo y confunden a Google.

¿Cuándo conviene añadir filtros o facetas?

Cuando el catálogo lo pide. Para 6-8 hijos, una rejilla limpia basta y los filtros añaden fricción sin valor. Para decenas o cientos (e-commerce), filtros por categoría/precio/marca + orden ayudan a encontrar; en móvil se pliegan en un drawer. Regla: la complejidad de navegación es proporcional al número real de hijos, no al deseo de parecer completo.

¿«Ver más» o el nombre del hijo como texto del enlace?

El nombre real del destino. El texto del enlace (anchor text) es lo que leen el visitante y el crawler: «Consultoría de desarrollo web» enseña; «ver más» / «clic aquí» es anchor muerto que no dice a dónde lleva, diluye el SEO y obliga a leer alrededor. Cada tarjeta enlaza a su ficha con su nombre propio.

¿Cuántas columnas debe tener la rejilla?

Mobile-first: una columna que crece con el ancho (1 → 2 → 4), el mismo .showcase del catálogo. El índice no inventa un grid propio —reusa el componente de tarjeta del sitio (CategoryCard/ProductCard)— para que productos, servicios y módulos se vean y se naveguen igual. Mantener una tarjeta mejora todas las secciones a la vez.

¿Para qué un índice si la home ya lista todo?

Porque hacen trabajos distintos: la home reparte ENTRE secciones (productos, servicios, blog…); el índice lista DENTRO de una. Meter el catálogo completo de cada sección en la home la vuelve infinita y le roba el trabajo de repartir. La home presenta cada sección con una tarjeta que enlaza a su índice; el índice agota la lista de esa rama.

Sigue por el sistema

Los niveles vecinos y los módulos que arman un índice.

¿Necesitas ayuda?