Cuál es el index de WordPress es una pregunta que parece simple hasta que descubres que hay varios archivos con ese nombre repartidos por la instalación, cada uno con una función distinta. El que está en la raíz arranca WordPress. Los que están en themes y plugins protegen las carpetas. Y el que vive dentro de tu tema controla qué plantilla se muestra cuando ninguna otra encaja. Confundirlos es el origen de errores silenciosos que afectan tanto al funcionamiento del sitio como a su visibilidad en buscadores.
WordPress no tiene un único index.php: tiene varios, y cada uno vive en un lugar diferente con una misión concreta. Tratarlos como el mismo archivo es el error más habitual cuando alguien empieza a explorar la estructura de su instalación.
El primero y más importante es el que está en la raíz del sitio, normalmente en /public_html/index.php o en la carpeta donde instalaste WordPress. Este archivo tiene exactamente una función: decirle al servidor que cargue WordPress. Su contenido es mínimo, apenas unas líneas que apuntan a wp-blog-header.php, que es quien realmente pone en marcha el motor. No muestra contenido por sí mismo; actúa como interruptor.
El segundo grupo son los archivos index.php vacíos que encontrarás dentro de las carpetas /wp-content/themes/, /wp-content/plugins/ y sus subdirectorios. Estos no hacen nada visible: su único propósito es evitar que un servidor mal configurado liste el contenido de esa carpeta a quien conozca la URL directa. Son una medida de seguridad pasiva, no código funcional.
El tercero es el index.php del tema activo, que vive en /wp-content/themes/tu-tema/index.php. Este sí tiene peso real: es la plantilla de último recurso de la Template Hierarchy de WordPress. Cuando el sistema busca qué plantilla usar para mostrar una URL y no encuentra ninguna más específica, cae aquí.
El index.php de la raíz no muestra nada; el del tema lo muestra todo cuando nada más encaja.
Imagina una tienda online de accesorios de fotografía. Cuando alguien visita la categoría /categoría/objetivos/, WordPress busca primero category-objetivos.php, después category.php, luego archive.php y, si ninguno existe en el tema, carga index.php. El visitante ve algo, pero probablemente sin el diseño específico que el propietario tenía en mente. El error no es visible en pantalla, pero la experiencia se degrada.
La Template Hierarchy es el sistema de reglas con el que WordPress decide qué archivo PHP del tema se usa para renderizar cada URL. Funciona de más específico a más genérico, y el index.php del tema está siempre al final de esa cadena.
Cuando alguien carga una URL, WordPress identifica el tipo de contenido que representa: ¿es una entrada individual, una página estática, un archivo de categoría, una búsqueda, un resultado de error 404? Para cada tipo existe una secuencia de plantillas que WordPress busca en orden. Si la primera no existe en el tema activo, pasa a la siguiente, y así sucesivamente hasta llegar a index.php.
Para una entrada individual (single post), el orden sería: single-{tipo}.php → single.php → singular.php → index.php. Para una página estática: custom-template.php (si tiene plantilla asignada) → page-{slug}.php → page-{id}.php → page.php → singular.php → index.php.
Esto tiene una implicación práctica directa: si tu tema solo tiene index.php y nada más, WordPress puede mostrar el sitio entero con ese único archivo. No es lo ideal para el diseño, pero técnicamente funciona. Algunos temas de desarrollo minimalista usan exactamente ese enfoque como punto de partida.
No hace falta mirar el código para saber qué plantilla carga cada URL. Con el modo depuración activado y el plugin Query Monitor instalado, verás en la barra de administración superior qué archivo de plantilla está sirviendo cada petición. Es el primer paso antes de crear o modificar cualquier plantilla en tu tema hijo.
El procedimiento es directo: instala Query Monitor, actívalo, navega a la URL que quieres inspeccionar y abre el panel Template en la barra de herramientas. Verás el archivo que se está usando y los que WordPress descartó por no encontrarlos. Si en una categoría importante aparece index.php en lugar de category.php, ya sabes qué crear para mejorar el control sobre ese tipo de página.
Modificar el index.php del tema activo es una operación legítima, pero tiene una regla que no admite excepciones: nunca edites el tema padre directamente. Cada actualización del tema sobrescribe los archivos modificados y pierdes todos los cambios.
La solución es trabajar siempre desde un tema hijo (child theme). Un tema hijo hereda todos los archivos del padre y solo aplica los que tú definas explícitamente. Para crear el archivo index.php en tu tema hijo:
/wp-content/themes/tu-tema-hijo/. Si no tienes tema hijo, créalo antes de continuar.index.php del tema padre a la carpeta de tu tema hijo. La ruta de origen sería /wp-content/themes/tu-tema-padre/index.php.El error habitual aquí es editar el archivo directamente desde el editor de WordPress (Apariencia > Editor de archivos de temas). Es posible hacerlo, pero un fallo de sintaxis PHP puede dejar el panel de administración inaccesible. Si lo haces, ten siempre acceso FTP o al gestor de archivos del hosting como vía de escape.
Imagina que gestionas un blog de viajes y necesitas que el index.php del tema muestre un mensaje diferente cuando no hay entradas en un archivo. Copias el archivo al tema hijo, localizas el bloque have_posts() y añades tu mensaje personalizado en el else. El tema padre queda intacto y tus cambios sobreviven a las actualizaciones.
Cuando alguien habla de «indexación» en WordPress en un contexto SEO, el archivo index.php de la raíz rara vez es el problema directo. Lo que sí puede bloquear la indexación de tu sitio son las configuraciones que ese archivo pone en marcha al ejecutar WordPress.
El punto de control más habitual está en Ajustes > Lectura, dentro del escritorio de WordPress. Allí existe la opción «Pedir a los motores de búsqueda que no indexen este sitio». Si está activada, WordPress añade una cabecera X-Robots-Tag: noindex a todas las páginas. Google Search Console te avisará de ello en el informe de Cobertura o en Indexación de páginas, dependiendo de la versión que uses.
El segundo factor que conecta la raíz con el SEO es el archivo wp-login.php y otros puntos de entrada que WordPress expone por defecto. No están relacionados con la indexación de contenido, pero sí con la seguridad del sitio, que a su vez afecta al tiempo de actividad y a cómo los rastreadores pueden acceder a tus páginas.
La recomendación actual es verificar en Google Search Console que tus URLs principales aparecen en el informe de Indexación de páginas como indexadas. Si aparecen con el motivo «Excluida por etiqueta noindex» y no recuerdas haberlo configurado así, el primer lugar donde mirar es exactamente esa opción en Ajustes > Lectura. Es una configuración que se activa por error durante el desarrollo y se olvida desactivar al publicar el sitio.
Los archivos index.php vacíos que WordPress coloca en las carpetas de plugins y themes son una capa de protección contra el directory listing, la posibilidad de que cualquier persona escriba una URL como tudominio.com/wp-content/plugins/ y vea el listado completo de los plugins que tienes instalados.
Conocer tus plugins facilita buscar vulnerabilidades específicas en versiones concretas. Es información que no debería ser pública. El archivo vacío responde con una página en blanco en lugar de un listado, cortando esa vía de información.
Sin embargo, esta protección solo funciona si el servidor no tiene activado el directory listing de forma independiente o si no hay otro mecanismo que lo evite. La forma más robusta de desactivarlo es añadir esta línea en tu archivo .htaccess (en servidores Apache):
Options -Indexes
Con eso, el servidor devuelve un error 403 en lugar de un listado, independientemente de si existe el index.php vacío. Los archivos vacíos siguen siendo útiles como segunda barrera, pero la directiva de .htaccess es la que realmente cierra la puerta.
Un matiz que conviene tener claro: nunca borres esos archivos index.php vacíos pensando que son innecesarios. Las actualizaciones de WordPress y de los plugins los regeneran, pero en el intervalo entre que los borras y la próxima actualización, la carpeta puede quedar expuesta en servidores mal configurados.
Saber que estos archivos existen no basta. Lo que marca la diferencia es verificar que cada uno está donde debe y hace lo que se espera. Este proceso te lleva menos de quince minutos la primera vez y puedes convertirlo en una revisión trimestral.
wp-blog-header.php. Si tiene código adicional que no recuerdas haber añadido, es una señal de alerta de seguridad.tudominio.com/wp-content/plugins/ desde el navegador. Si ves un listado de carpetas, la protección no está funcionando. Si ves una página en blanco o un error 403, está bien.index.php cuando debería tener una plantilla más específica.Una instalación de WordPress sana no es la que tiene el código más complejo; es la que tiene cada archivo en su lugar y haciendo exactamente lo que se espera de él.
Si tras esta auditoría detectas que alguna de tus URLs clave está usando index.php como plantilla de emergencia, el siguiente paso es crear la plantilla específica que corresponde en tu tema hijo. Query Monitor ya te habrá dicho cuál es. Con el nombre correcto, WordPress la detectará automáticamente en la próxima carga sin necesidad de tocar ninguna configuración adicional.
No. El index.php de la raíz es el punto de entrada de WordPress: sin él, el servidor no sabe cómo arrancar la aplicación y el sitio devuelve un error. Si lo borras por accidente, puedes recuperarlo subiendo una copia limpia desde una instalación de WordPress de la misma versión. El contenido y la base de datos no se ven afectados.
Un error de sintaxis PHP puede dejar el panel de administración inaccesible. Si eso ocurre, conéctate por FTP o desde el gestor de archivos del hosting, navega a la carpeta del tema y sube la versión anterior del archivo. Para evitar este riesgo, trabaja siempre desde un tema hijo y haz una copia de seguridad antes de cualquier modificación.
No tienen ningún impacto en el rendimiento. Son archivos de texto de pocos bytes que el servidor solo sirve si alguien accede directamente a la URL de esa carpeta. En condiciones normales de navegación, nunca se cargan. Su función es exclusivamente preventiva frente al listado de directorios.
El síntoma más claro es que tus páginas no aparecen en Google o en Search Console aparecen como excluidas por noindex. El primer lugar donde mirar es Ajustes > Lectura en el escritorio de WordPress. Si la opción de bloqueo a buscadores está activa, desactívala y solicita una nueva indexación desde Search Console.
Técnicamente sí. WordPress usa index.php como plantilla de último recurso para cualquier tipo de contenido. El sitio funciona, pero sin plantillas específicas pierdes control sobre el diseño de cada tipo de página. Es una situación válida en desarrollo o para temas minimalistas, pero no es lo recomendable para un sitio en producción.
El archivo en sí no provoca penalizaciones. Lo que puede afectar al posicionamiento es lo que se configura a través de él: si un error en el código genera páginas vacías, redirecciones incorrectas o bloqueos al rastreador, Google puede dejar de indexar esas URLs. El riesgo es funcional, no una penalización manual.
Depende de lo que quieras hacer. Verificar que existen y que la configuración de visibilidad es correcta no requiere PHP. Modificar el index.php del tema para personalizar plantillas sí requiere un nivel básico de PHP y de la estructura de temas de WordPress. Para cambios de diseño simples, los constructores de páginas o los ajustes del personalizador suelen ser suficientes.