SSH para desarrolladores de WordPress: 10 comandos que salvaran su vida

Como desarrollador de WordPress, probablemente pasa mucho tiempo en un clientes FTP (FileZilla) o panel de hosting. Eso es un error. Lo que toma 15 minutos en FTP (ej. eliminar una carpeta cache con 100,000 archivos) toma 2 segundos en la terminal SSH.

En esta guía, le mostrare un conjunto de comandos que los desarrolladores sénior no pueden imaginar trabajar sin ellos.

#Por qué todo desarrollador de WordPress necesita SSH

Antes de sumergirnos en los comandos, entendamos por qué SSH es transformador para el desarrollo de WordPress:

• Velocidad: Las operaciones se ejecutan a la velocidad del disco del servidor, no de su conexión a internet
• Automatización: Puede crear scripts que automatizan tareas repetitivas
• Depuración en vivo: Vea errores en tiempo real mientras se producen
• Gestión remota: Administre servidores desde cualquier lugar del mundo
• Seguridad: Conexión cifrada de extremo a extremo

#Configuración inicial de SSH

Si nunca ha usado SSH, aquí está como comenzar:

## Generar par de claves SSH (solo la primera vez)
ssh-keygen -t ed25519 -C "[email protected]"

## Copiar clave publica al servidor
ssh-copy-id usuario@ip-del-servidor

## Conectarse al servidor
ssh usuario@ip-del-servidor

La autenticación por claves es más segura que contraseñas y elimina la necesidad de escribir la contraseña cada vez.

#1. Análisis de disco: ¿Qué está consumiendo mi espacio?

Cuando el hosting grita “Cuota Excedida”, FileZilla no ayudara. Use esto:

#du (disk usage)

## Mostrar carpetas en el directorio actual, ordenadas por tamaño
du -h --max-depth=1 | sort -hr

Ejemplo de salida:

2.1G    ./wp-content
450M    ./wp-content/uploads
380M    ./wp-content/cache
120M    ./wp-content/plugins
45M     ./wp-admin
12M     ./wp-includes

Inmediatamente puede ver que la carpeta de cache consume 380MB y puede ser limpiada de forma segura.

#ncdu (ncurses disk usage)

Si puede, ejecute ncdu. Es un gestor interactivo que navega con las flechas. Un absoluto “cambio de juego” para la limpieza de servidores.

## Instalar ncdu (si no esta disponible)
apt-get install ncdu  # Debian/Ubuntu
yum install ncdu      # CentOS/RHEL

## Ejecutar en el directorio de WordPress
ncdu /var/www/html

Recurra a du cuando necesite una cifra que pegar en un ticket, y a ncdu cuando todavía no sepa qué está buscando. Los dos recorren el árbol completo y eso no sale gratis: en una carpeta uploads grande mantienen el disco ocupado durante un minuto, y en alojamiento compartido eso se nota como páginas más lentas mientras corren. Si el sitio tiene visitas, apúntelos a un subdirectorio en lugar de a la raíz de la cuenta. Ninguno le dirá qué se puede borrar, y en una instalación de WordPress el candidato que más sorprende no suelen ser las imágenes sino las revisiones y los registros que algunos plugins de seguridad guardan en disco durante meses.

#2. Logs: Depuración en tiempo real

En lugar de descargar debug.log, abrirlo con Bloc de Notas y buscar errores… véalos en vivo!

#tail -f

## Seguir las ultimás líneas del archivo en tiempo real
tail -f wp-content/debug.log

Ahora refresque la página en su navegador, y los errores aparecerán en pantalla. Salga con Ctrl+C.

#Filtrar logs en tiempo real

## Solo ver errores fatales
tail -f wp-content/debug.log | grep -i "fatal"

## Ver errores de un plugin específico
tail -f wp-content/debug.log | grep "woocommerce"

## Mostrar las ultimás 100 líneas y luego seguir
tail -100f wp-content/debug.log

#Logs del servidor web

Además del debug.log de WordPress, los logs del servidor web son invaluables:

## Apache - ver errores
tail -f /var/log/apache2/error.log

## Nginx - ver errores
tail -f /var/log/nginx/error.log

## Ver solicitudes 404 en tiempo real
tail -f /var/log/apache2/access.log | grep " 404 "

Seguir el log en vivo funciona mientras pueda provocar el error a voluntad. Cuando no puede, la línea que le interesa ya pasó, así que empiece por tail -n 200 wp-content/debug.log y lea hacia atrás. Dos detalles se le escapan a casi todo el mundo. El archivo solo existe si WP_DEBUG_LOG está activo en wp-config.php, de modo que una terminal vacía suele significar que el registro está apagado, no que el sitio esté sano. Y nada rota ese archivo por su cuenta, así que un sitio que lanza un aviso en cada petición termina siendo él mismo quien llena la cuota que diagnosticó en la sección anterior.

#3. Búsqueda de archivos: Donde está ese código?!

Buscando donde se uso add_image_size? No descargue todo el proyecto.

#grep

## Buscar la frase "add_image_size" en todos los archivos PHP recursivamente
grep -r "add_image_size" .

Si solo quiere una lista de archivos (sin contenido):

grep -rl "add_image_size" .

#Búsquedas avanzadas con grep

## Buscar con contexto (3 líneas antes y despues)
grep -r -C 3 "wp_enqueue_script" wp-content/themes/

## Buscar solo en archivos PHP
grep -r --include="*.php" "add_action" wp-content/plugins/

## Buscar excluyendo directorios
grep -r --exclude-dir={node_modules,vendor,.git} "API_KEY" .

## Contar ocurrencias
grep -rc "do_action" wp-content/plugins/ | sort -t: -k2 -rn | head -10

La forma completa sirve para leer el código alrededor del resultado, y la versión con -l cuando solo quiere saber qué plugin es responsable de un comportamiento. Dentro de un tema el coste es despreciable, dentro de wp-content/plugins no lo es, porque la recursión entra en cada carpeta vendor que encuentre. Confirme un resultado abriendo el archivo en esa línea en lugar de fiarse del recuento: el mismo nombre de función aparece en el código del plugin, en el bloque de documentación que lo precede y en el archivo de traducción, y solo uno de esos tres sitios es la definición.

#4. Permisos: Arreglar “403 Forbidden”

A menudo después de una migración, los archivos tienen permisos incorrectos. Recuerde la regla:

• Directorios: 755
• Archivos: 644

#find + chmod

No lo haga manualmente. Automatícelo:

## Establecer 755 para todos los directorios
find . -type d -exec chmod 755 {} \;

## Establecer 644 para todos los archivos
find . -type f -exec chmod 644 {} \;

#Permisos especiales de seguridad

## wp-config.php debe ser más restrictivo
chmod 400 wp-config.php

## .htaccess
chmod 444 .htaccess

## Verificar propietario de los archivos
chown -R www-data:www-data /var/www/html/

Ejecute esto cuando tenga un síntoma, un 403 o una subida que falla, y no como mantenimiento rutinario. Un chmod aplicado a todo aplana cualquier excepción deliberada de la instalación, y la que importa es wp-config.php, que guarda las credenciales de la base de datos. El bucle solo toca los archivos que pertenecen a su usuario, de manera que en un alojamiento donde el servidor web corre con otra cuenta puede no arreglar nada y no devolver ningún error. Compruebe el resultado con ls -l wp-config.php y cargando la página que fallaba, nunca repitiendo el mismo comando.

#5. Respaldos: Archivo rápido

Quiere un respaldo rápido antes de una actualización? No copie vía FTP (tarda una eternidad). Comprímalo en el servidor.

#tar

## Crear archivo backup.tar.gz del directorio actual
tar -czf backup.tar.gz .

Descomprimir:

tar -xzf backup.tar.gz

#Respaldos con fecha

## Crear respaldo con marca de tiempo
tar -czf backup-$(date +%Y%m%d-%H%M).tar.gz .

## Excluir carpetas innecesarias del respaldo
tar -czf backup.tar.gz --exclude='./wp-content/cache' --exclude='./wp-content/uploads/cache' .

Comprimir en el servidor es el movimiento correcto antes de actualizar un plugin, porque el archivo nunca atraviesa su conexión. No es una estrategia de respaldo: el paquete queda en el mismo disco que el sitio, así que sobrevive a una actualización fallida pero no a una avería del volumen. Y antes de confiar en él, mire dentro con tar -tzf backup.tar.gz | head, porque un archivo que se cortó a mitad de escritura por falta de espacio aparece en el listado como un archivo perfectamente normal.

#6. Base de datos (WP-CLI)

Si tiene WP-CLI (y debería), no necesita phpMyAdmin.

## Exportar base de datos
wp db export backup.sql

## Importar base de datos
wp db import backup.sql

## Buscar y reemplazar (migración)
wp search-replace 'sitio-viejo.com' 'sitio-nuevo.com' --all-tables

## Listar usuarios
wp user list

## Cambiar contraseña
wp user update 1 --user_pass="NuevaContrasena2026"

## Desactivar todos los plugins (emergencia)
wp plugin deactivate --all

## Verificar integridad del core
wp core verify-checksums

#Comandos WP-CLI avanzados

## Optimizar base de datos
wp db optimize

## Ver tamaño de tablas
wp db size --tables

## Buscar en la base de datos
wp db search "texto_sospechoso"

## Regenerar miniaturas de imagenes
wp media regenerate --yes

## Limpiar transients expirados
wp transient delete --expired

WP-CLI corre como su usuario de shell y no a través del servidor web, por lo que los límites de subida y max_execution_time dejan de aplicarse. Lo que no puede ignorar es que el sitio está en producción: wp db import elimina y vuelve a crear las tablas mientras alguien está comprando, así que la ventana de mantenimiento forma parte del comando y no es un añadido. Un detalle que ahorra horas: haga siempre wp search-replace con --dry-run antes de escribir, porque el dominio antiguo vive dentro de arrays PHP serializados donde cada cadena lleva su propia longitud, y un reemplazo hecho por SQL deja esa longitud mal y vacía los widgets.

#7. Eliminación masiva de archivos

Eliminar una carpeta de plugin cache con un millón de archivos pequeños vía FTP puede tomar una hora.

#rm

## Eliminar carpeta y todo su contenido (sin deshacer!)
rm -rf wp-content/cache/

Tiempo empleado: 0.5 segundos.

#Eliminación segura

## Ver que se eliminaria primero (dry run)
find wp-content/cache/ -type f | head -20

## Contar archivos antes de eliminar
find wp-content/cache/ -type f | wc -l

## Eliminar archivos más antiguos de 30 dias
find wp-content/cache/ -type f -mtime +30 -delete

Es la herramienta correcta para un directorio de cache y casi nunca la correcta para nada más, porque no pregunta antes ni deja deshacer después. El hábito que le salva es ejecutar ls sobre exactamente la misma ruta primero y borrar solo cuando el listado coincide con lo que tenía en la cabeza. Vigile sobre todo el final de la ruta, porque un espacio de más convierte un objetivo en dos, y el segundo suele ser el directorio padre. En un sitio con tráfico el plugin reconstruye la cache en la siguiente petición, de modo que el precio es una carga lenta y no una caída.

#8. Transferencia de archivos entre servidores

Cuando necesita mover archivos entre servidores:

#rsync

## Sincronizar archivos al servidor remoto
rsync -avz --progress /local/path/ usuario@servidor:/remoto/path/

## Sincronizar solo archivos cambiados
rsync -avz --progress --update /local/ usuario@servidor:/remoto/

## Excluir archivos innecesarios
rsync -avz --exclude='node_modules' --exclude='.git' /local/ usuario@servidor:/remoto/

#scp para transferencias simples

## Copiar archivo al servidor
scp backup.sql usuario@servidor:/ruta/destino/

## Copiar archivo desde el servidor
scp usuario@servidor:/ruta/archivo.sql ./local/

La barra final en la ruta de origen significa “el contenido de esta carpeta”; sin ella acaba con uploads/uploads anidado. Y --delete refleja también los borrados, es decir, elimina en el destino todo lo que ya no existe en local: lanzado desde una copia local desactualizada, ese parámetro vacía la biblioteca de medios en lugar de sincronizarla. Por eso la primera pasada se hace siempre con -n, que enseña la lista sin tocar nada. rsync además tiene que estar instalado en los dos extremos, y cuando falta en el servidor el comando falla al instante en vez de degradarse a otra cosa.

#9. Monitorización del servidor

#Uso de recursos en tiempo real

## Ver procesos que consumen más recursos
top

## Version mejorada (si disponible)
htop

## Ver uso de memoria
free -h

## Ver uso de disco por particion
df -h

## Ver conexiónes de red activas
netstat -tuln

#Identificar procesos PHP pesados

## Ver procesos PHP activos
ps aux | grep php

## Ver consultas MySQL lentas
mysqladmin -u root -p processlist

Estos comandos responden a una pregunta distinta de la del disco: no qué ocupa espacio, sino qué está consumiendo el procesador ahora mismo. Cuando vea varios procesos PHP fijos arriba en la lista, el culpable casi nunca es WordPress en sí, sino una consulta lenta o un cron que se solapa consigo mismo porque la ejecución anterior todavía no terminó. Compruebe esa hipótesis con wp cron event list antes de tocar el servidor. Y tenga presente que en alojamiento compartido usted ve procesos de toda la máquina, así que una carga alta puede no tener nada que ver con su sitio.

#10. Aliases y scripts de productividad

Cree aliases para comandos que usa frecuentemente:

## Agregar a ~/.bashrc o ~/.zshrc
alias wplog='tail -f wp-content/debug.log'
alias wpsize='du -h --max-depth=1 | sort -hr'
alias wpcache='rm -rf wp-content/cache/*'
alias wpdb='wp db export backup-$(date +%Y%m%d).sql'
alias wpcheck='wp core verify-checksums && wp plugin list --update=available'

#Script de mantenimiento automatizado

#!/bin/bash
## Script de mantenimiento diario de WordPress
echo "=== Mantenimiento WordPress $(date) ==="

## Respaldo de base de datos
wp db export /respaldos/db-$(date +%Y%m%d).sql
echo "Base de datos respaldada"

## Verificar integridad del core
wp core verify-checksums
echo "Core verificado"

## Listar actualizaciones disponibles
echo "=== Actualizaciones disponibles ==="
wp plugin list --update=available
wp theme list --update=available
wp core check-update

## Limpiar transients
wp transient delete --expired
echo "Transients limpiados"

## Optimizar base de datos
wp db optimize
echo "Base de datos optimizada"

echo "=== Mantenimiento completo ==="

Los alias son cómodos y también la forma más fácil de ejecutar en producción algo que creía estar ejecutando en pruebas. Deje que el nombre diga dónde actúa, y no lo abrevie tanto que se pueda escribir por accidente. Para cualquier script de mantenimiento, la regla es la misma que en el resto del artículo: primero el respaldo, después la operación, y una comprobación al final que falle de forma visible. Un script que borra y no verifica nada solo le informa de que se ejecutó, no de que funcionó.

#Cuando el alojamiento solo ofrece SFTP

Algunos planes compartidos anuncian SSH y entregan SFTP, es decir, transferencia de archivos por el mismo protocolo pero sin shell al otro lado. Se descubre en el momento en que ssh usuario@host 'ls' responde exec request failed on channel 0. Nada de lo que en esta guía se ejecuta en el servidor sobrevive a eso: ni du, ni tar, ni WP-CLI, porque no hay ningún proceso donde puedan correr. La capa de transferencia sigue viva, así que sftp y rsync por encima de ella mueven archivos mejor que cualquier cliente con ventana, y el trabajo sobre la base de datos vuelve al navegador, a phpMyAdmin y a un plugin de copias. Antes de darlo por perdido, mire si el proveedor ofrece shell en otro puerto o la activa cuando se pide, porque en bastantes casos es un ajuste y no un límite del producto. Si de verdad no está en ese plan, tiene un argumento concreto para plantear un cambio, porque todos los flujos de trabajo anteriores le quedan cerrados.

#Resumen

La terminal SSH no muerde. Le permite trabajar a la velocidad del disco del servidor, no a la velocidad de su conexión a internet. Comience con ncdu y tail -f — no querrá volver a hacer clic con el ratón.

Los comandos esenciales para empezar:

1. du / ncdu - Análisis de espacio en disco
2. tail -f - Depuración en tiempo real
3. grep -r - Búsqueda de código
4. find + chmod - Corrección de permisos
5. tar - Respaldos rápidos
6. wp (WP-CLI) - Gestión completa de WordPress
7. rm -rf - Eliminación rápida (con precaución!)
8. rsync - Transferencia eficiente de archivos
9. top / htop - Monitorización de recursos
10. Aliases - Productividad automatizada

Conozca más sobre los servicios de desarrollo WordPress en WPPoland.