Cómo conseguir más usuarios para tu plugin en WordPress.org (si eres desarrollador esta guía está dedicada a ti)

Si has publicado un plugin en WordPress.org y te encuentras con esas temidas «Menos de 10 instalaciones activas», no estás solo.

La mayoría de plugins en el directorio de WordPress.org tienen muy pocos usuarios, y no siempre es porque el código sea malo o la idea no sea buena. A menudo, el problema está en cómo presentas tu plugin y en público (que lo has hecho, por si no te había dado cuenta) en las decisiones que tomas antes incluso de empezar a programarlo.

El proceso de subir un plugin en WordPress.org (https://es.wordpress.org/plugins/developers/add/) es una tarea a veces larga, tediosa, que requiere revisiones de código, y más pasos de los que uno querría.

Si a eso le sumamos que luego resulta que todo ese esfuerzo no parece haber servido a nada ni a nadie pues como que se te quedan pocas ganas de subir más plugins.

En esta guía quiero mostrarte algunos consejos que puedes aplicar por tu cuenta y gratis, desde la idea inicial hasta la publicación y más allá, para que tu plugin llegue a más gente. Nada de teorías complicadas: solo consejos prácticos que incluso yo mismo, cuando los sigo y no me pongo tontorrón, también me funcionan.

Antes de programar: planifica pensando en los usuarios

El error más común es programar algo porque sabes hacerlo, no porque alguien lo necesite. Antes de escribir una línea de código, hazte algunas preguntas, que luego todo son lamentos.

¿Tu plugin resuelve un problema real?

No pienses, en serio, investiga, es fácil:

• Busca en los foros de soporte de WordPress.org qué problemas tienen los usuarios sin solucionar.
• Mira plugins similares y lee las valoraciones de 1 y 2 estrellas: ahí encontrarás qué falla y qué necesita la gente.
• Identifica plugins populares que hace mucho tiempo que no se actualizan.

La información está ahí, solo tienes que saber verla.

¿Ya hay 50 plugins que hacen lo mismo?

Competir con Yoast SEO, Wordfence o WooCommerce es casi imposible si empiezas de cero. En cambio, busca nichos más pequeños.

Por ejemplo, en lugar de «El mejor plugin de seguridad general», crea «Anti-Cache Emergency Kit» que resuelva un problema concreto con las puñeteras cachés.

Fíjate también, por ejemplo, así a lo loco, que se me acaba de ocurrir, en «Easy Actions Scheduler Cleaner». No intenta ser un plugin completo de optimización, solo limpia una cosa específica y lo hace bien, incluso muy requetebién diría yo.

¿Tu plugin es una pequeña gran solución?

Los plugins con más éxito no siempre son los más complejos. A veces una solución sencilla a un problema frecuente vale más que una suite completa.

Yo mismo tengo por ahí el de «No Gutenberg» con más de 10.000 instalaciones activas porque resuelve una necesidad clara de forma directa.

Y si quieres un ejemplo más claro ahí está Contact Form 7. Hay montones de plugins de formularios de contacto más avanzados, algunos hasta con maquetación visual y herramientas de arrastrar y soltar pero no le llegan ni de lejos a su éxito.

¿Freemium o totalmente gratis?

Decide desde el principio tu modelo. Cada vez hay más plugins en WordPress.org que son meros ganchos para vender una versión premium, y los usuarios lo notan. La frustración crece cuando descargan un plugin que promete hacer X pero en realidad solo muestra anuncios de «actualiza a PRO para usar esta función».

Si vas a ir a tope con el freemium

• La versión gratuita debe ser ÚTIL por sí sola, no una demo.
• Resuelve al menos un problema completo en la versión gratis.
• Deja claro en el readme qué incluye gratis y qué es premium.
• No llenes el admin de anuncios de «Upgrade to PRO».

Si apuestas por el gratis total

• Tienes ventaja competitiva clara frente a freemiums.
• Los usuarios lo valoran mucho, porque además cada vez hay menos, y es más probable que dejen buenas reseñas.
• Puedes monetizar de otras formas: donaciones, servicios relacionados, consultoría.

Los plugins que mejor funcionan son los que dan valor real en la versión gratuita. No Gutenberg, con más de 10.000 instalaciones es totalmente gratis y hace exactamente lo que promete. Los usuarios lo agradecen/emos.

El nombre y título: tu primera (y quizás última) oportunidad

El título de tu plugin es lo primero que ve la gente en las búsquedas. Aquí es donde muchos desarrolladores fallan/mos rotundamente.

Incluye palabras clave descriptivas, no solo tu marca

• Mal: AyudaWP Tools
• Bien: Easy Actions Scheduler Cleaner by AyudaWP

El segundo título dice exactamente qué hace el plugin e incluye palabras que la gente busca: «actions scheduler», «cleaner». Si alguien busca «limpiar actions scheduler», tu plugin aparecerá.

Cómo elegir un buen título:

• Pon las palabras clave principales al principio.
• Usa entre 2 y 5 términos que la gente buscaría.
• Puedes añadir tu marca al final, pero no empieces con ella.
• Máximo 60 caracteres para que se vea completo en los resultados

Ejemplos de plugins (míos) que lo hacen bien:

• No Gutenberg – Disable Blocks Editor and Global Styles – Back to Classic Editor: (describe perfectamente qué hace)
• SEO Read More Buttons – AyudaWP: (incluye SEO y Read More, términos que la gente busca)

Ejemplo de plugins (míos) que podría debería mejorar:

• Anti-Cache Emergency Kit: podría ser Clear Cache Emergency Kit - Fix Cache Problems Fast, y funcionaría seguramente mejor.

El readme.txt: tu carta de presentación

El readme.txt es el archivo más importante de tu plugin después del código. Aquí es donde más habitualmente pierdes o ganas usuarios.

La estructura base, que debes aprovechar, es esta:

=== Plugin Name ===
Contributors: (esto debe ser una lista de slugs de usuario de wordpress.org)
Donate link: https://ejemplo.com/
Tags: tag1, tag2
Requires at least: 4.7
Tested up to: 5.4
Stable tag: 4.3
Requires PHP: 7.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Aquí va una descripción breve del plugin. No debe tener más de 150 caracteres. Sin Markdown.

== Description ==

Esta es la descripción larga. No hay límite, y puedes usar Markdown (y también en las siguientes secciones).

Por cuestiones de retro-compatibilidad, si falta esta sección, se usará la longitud completa de la descripción breve, y
se procesará el Markdown.

Unas pocas notas sobre las secciones anteriores:

* "Contributors" es una lista separada por comas de nombres de usuario de wordpress.org
* "Tags" es una lista separada por comas de etiquetas que tienen que ver con el plugin
* "Requires at least" es la versión mínima en la que funcionará el plugin
* "Tested up to" esa la versión máxima en la que tú has *probado el plugin y funciona*
* "Stable tag" debe indicar la "tag" en Subversion de la última versión estable

Ten en cuenta que el valor en el `readme.txt` de la stable tag es el que está definiendo para el plugin. Si el archivo `/trunk/readme.txt` dice que la stable tag es la `4.3`, entonces es el `/tags/4.3/readme.txt` el que se usará para mostrar la información del plugin.

Si desarrollas en la carpeta trunk, puedes actualizar el `readme.txt` en trunk para reflejar cambios en tu versión en desarrollo, si que se muestre incorrectamente información sobre la versión estable actual que no tenga esos cambios -- ya que el `readme.txt` de trunk apunta a la stable tag correcta.

Si no se indica ninguna stable tag, tus usuarios podrían no tener la versión correcta de tu código.

== Frequently Asked Questions ==

= Una pregunta que alguien podría tener en mente =

Una respuesta a esa pregunta.

= ¿Qué pasa con el fistro diodenal? =

Respuesta al dilema del fistro diondenal.

== Screenshots ==

1. Esta descripción de captura de pantalla corresponde a screenshot-1.(png|jpg|jpeg|gif). Los screenshots se almacenan en el directorio /assets.
2. Descripción de la segunda captura de pantalla

== Changelog ==

= 1.0 =
* Un cambio desde la versión anterior.
* Otro cambio.

= 0.5 =
* Lista versiones desde la más reciente en la parte superior a la más antigua al fondo.

== Upgrade Notice ==

= 1.0 =
Los avisos de actualización describen el motivo por el que un usuario debería actualizar. No pongas más de 300 caracteres.

= 0.5 =
Esta versión corrige un fallo de seguridad. Actualiza inmediatamente.

== Un breve ejemplo de Markdown ==

Markdown es lo que el analizador usa para procesar la mayoría del archivo readme.

[markdown syntax]: https://daringfireball.net/projects/markdown/syntax

Lista ordenada:

1. Una funcionalidad
1. Otra funcionalidad
1. Algo más sobre el plugin

Lista de viñetas:

* algo
* algo más
* otra cosa

Los enlaces requieren corchetes y paréntesis:

Esto es un enlace a [WordPress](https://es.wordpress.org/ "Tu software favorito") y otro a [la documentación de sintaxis de Markdown][markdown syntax]. Los títulos de los enlaces son opcionales.

Las citas son como en los emails:

> Asteriscos para *resaltar*. Dobles asteriscos para **negritas**.

Y comillas inversas para el código:

`<?php code(); ?>`

Short Description (máximo 150 caracteres)

Ve directo al grano. No vendas, describe qué hace el plugin en una frase clara.

• Mal: El mejor plugin para gestionar tu tienda.
• Bien: Simplifica la gestión de WooCommerce con herramientas rápidas para productos, pedidos y clientes.

Long Description (completa pero al grano)

• Empieza con un párrafo que explique el problema que resuelves.
• Lista las características principales (usa viñetas, son más legibles).
• Sé concreto: en lugar de «optimiza tu web», escribe «reduce el tamaño de la base de datos eliminando revisiones antiguas».
• No uses lenguaje de ventas agresivo: recuerda que estás en WordPress.org, no vendiendo en tu web.
• Mantén el readme por debajo de 10k de tamaño, que no termine pesando más que el plugin.
• Evita el exceso de emojis: alguno puntual está bien pero últimamente hay exceso y termina pareciendo un pastel en vez de un texto técnico.

Tags (etiquetas las justas)

• Solo las 5 primeras etiquetas cuentan para las búsquedas (de hecho verás una advertencia si usas más).
• Usa términos específicos que la gente ya busca, no seas pitoniso, no eres Apple, no creas tendencia.
• No pongas tags de marcas de la competencia (está feo, y además va contra las normas).
  Ejemplo: para un plugin de WooCommerce, usa «woocommerce», no «easy-digital-downloads».

El «Tested up to» importa más de lo que piensas

Mantén este valor actualizado. Los usuarios desconfían de plugins que no se han probado con las últimas versiones de WordPress. No necesitas actualizarlo en cada versión menor (6.4.1, 6.4.2…), solo en las mayores (6.7, 6.8, 6.9…).

Changelog (si está vacío mal, si te pasas te conviertes en Elemen… no sigo)

Muestra que el plugin está vivo. Si tienes muchas versiones, guarda solo las recientes en el readme y el historial completo en un changelog.txt en tu web, por ejemplo.

Igualmente, es bueno que esté traducido a los mismos idiomas en los que esté disponible el plugin, y sobre todo que no sea excesivamente técnico, que cualquier usuario pueda entender qué cambia en cada versión.

Debes ser consciente de que es un elemento de confianza o miedo para el usuario final ante cada actualización.

Las imágenes son lo primero que se ve de tu plugin

Icono

• Tamaño: 128×128 px (versión normal) y 256×256 px (retina).
• Usa SVG si puedes, se ve perfecto en cualquier tamaño.
• Diseño simple y reconocible.
• Evita texto en el icono, usa símbolos o formas (¿ves?, esto yo lo hago fatal).
• Debe verse bien en pequeño, es donde más se usa.

Banner

• El banner aparece en la página del plugin en WordPress.org y en los detalles del buscador.
• Tamaño: 772×250 px (normal) y 1544×500 px (retina).
• No incluyas el nombre del plugin en texto (ya aparece).
• Muestra visualmente qué hace o qué problema resuelve.
• Diseño limpio, evita saturar con información.
• Puedes crear versiones para idiomas de cada tamaño (lo explico luego ampliamente).
• Puedes crear versiones para idiomas RTL (right-to-left) añadiendo –rtl al nombre del archivo.

Screenshots

• Crea varios screenshots-X.png (donde X es 1, 2, 3…), no racanees con la información visual al usuario.
• Guárdalos en la carpeta /assets de tu repositorio SVN.
• Máximo 10MB por imagen, pero cuanto más ligeras mejor.
• Muestra la interfaz real del plugin.
• En el readme, añade descripciones numeradas en la sección == Screenshots ==.
• Puedes crear versiones para idiomas de cada captura (luego lo explico).
• Prioriza: página de configuración, resultado en el front-end, características especiales.

Las imágenes van en la carpeta /assets de tu repositorio SVN, NO en subcarpetas de /trunk ni de tus /tags.

La gente es visual, o sea, somos visuales, tú eres gente, yo también, y el resto de humanos no es diferente. Un plugin sin imágenes tiene muchas menos descargas que uno con assets bien hechos.

Vista previa: la demo interactiva que casi nadie usa (y debería)

Los vistas previas de plugins son una de las funcionalidades más recientes y potentes de WordPress.org, pero muy pocos desarrolladores las conocen o aprovechan. Utilizan un archivo llamado blueprint que permite que los usuarios prueben tu plugin EN VIVO, directamente desde WordPress.org, sin instalar nada en su servidor.

¿Qué es un blueprint?

Es un archivo JSON (blueprint.json) que defines en tu repositorio y que crea una instalación temporal de WordPress con tu plugin ya activado. Cuando un usuario hace clic en «Vista previa», WordPress.org genera una instancia efímera en la web de Playground donde puede probar tu plugin inmediatamente.

Por qué es una ventaja competitiva enorme

• Los usuarios pueden ver tu plugin funcionando ANTES de instalarlo.
• Reduces la barrera de entrada: no hace falta instalar para probar.
• Es mucho más efectivo que capturas de pantalla estáticas.
• Muy pocos plugins lo tienen todavía, así que destacas inmediatamente.
• Genera más confianza que cualquier descripción o captura de pantalla.

¿De verdad funciona?

Casi no hace falta que le preguntes a nadie, piensa tú en tu cabecita esto un momento para dos plugins similares en una búsqueda:

• Plugin A: descripción, capturas de pantalla estáticas.
• Plugin B: descripción, capturas de pantalla estáticas, Y botón de «Vista previa».

¿Cuál crees que genera más confianza? ¿Cuál instalarán más usuarios?

Los blueprints son especialmente efectivos para usuarios indecisos. Pueden probar tu plugin en 30 segundos sin tocar su web real. Si les gusta lo que ven, la conversión a instalación es mucho mayor.

Casos de uso ideales para añadir un blueprint.json

• Plugins visuales: Sliders, galerías, constructores de páginas
• Plugins de formularios: El usuario puede ver y probar el formulario
• Plugins de WooCommerce: Muestra cómo modifica la tienda
• Plugins de personalización: Demuestra el antes y después
• Plugins con interfaces complejas: Permite explorar sin comprometerse

Cuándo NO necesitas un blueprint.json

• Plugins muy simples sin interfaz visual (ejemplo: «deshabilitar emojis»).
• Plugins que solo trabajan en el admin sin resultados visibles.
• Plugins que requieren claves API o servicios externos obligatorios.

Cómo implementarlo

Puedes personalizar la experiencia para que los usuarios vean directamente tu plugin en acción: enviarlos a la página de configuración, crear contenido de ejemplo, instalar plugins complementarios como WooCommerce, etc.

Si quieres aprender a crear y optimizar tu blueprint.json paso a paso, aquí tengo una guía completa sobre cómo hacer los blueprint.json.

Cómo «imaginarlo»

Crea el blueprint pensando en la primera impresión. Tienes 30 segundos de atención del usuario. Asegúrate de que en esos 30 segundos vean lo mejor de tu plugin funcionando, no una pantalla de configuración vacía o una instalación limpia de WordPress.

Los blueprints son relativamente nuevos. Implementarlos ahora te da ventaja antes de que se vuelvan estándar y todos los plugins los tengan.

Idiomas: eso que los angloparlantes ignoran pero nosotros no

Si tu plugin solo está en inglés, estás dejando fuera a más del 70% de los usuarios potenciales de WordPress. Los desarrolladores angloparlantes no lo valoran porque – creen que – no lo necesitan, pero para el resto del planeta es determinante.

Por qué importa tanto la internacionalización

• WordPress.org tiene versiones en decenas de idiomas.
• Los usuarios buscan y filtran plugins en su idioma.
• Un plugin traducido genera más confianza.
• Las valoraciones positivas aumentan cuando los usuarios ven el plugin en su idioma.

Prepara tu plugin para traducción desde el principio

• Usa funciones de traducción en todos los textos: __(), _e(), esc_html__(), etc.
• Define correctamente el text domain en el archivo principal del plugin.
• No necesitas incluir load_plugin_textdomain() si tu plugin está en WordPress.org (desde WordPress 4.6 se carga automáticamente).
• Nota: Los textos del código (comentarios, textos por defecto) deben estar en inglés.

Traducciones del contenido

El readme.txt y las cadenas de texto del plugin se traducen a través de translate.wordpress.org (GlotPress). Una vez publicado tu plugin, la comunidad puede contribuir con traducciones. Cuantos más idiomas tenga tu plugin traducidos, más usuarios llegarás a alcanzar.

Imágenes en varios idiomas

Aquí es donde realmente marcas diferencia, porque es algo que destaca a simple vista. Puedes crear versiones de tus assets para cada idioma que esté disponible, e ir añadiendo más a medida que tu plugin esté traducido en más idiomas.

Screenshots

• screenshot-1.png (versión por defecto)
• screenshot-1-es_ES.png (captura en español)
• screenshot-1-fr_FR.png (captura en francés)

Si tu plugin tiene una interfaz en español y capturas en español, los usuarios hispanohablantes verán exactamente cómo se verá en su idioma. Esto aumenta enormemente la confianza y las instalaciones.

Casi nadie, ni siquiera grandes empresas, ofrece versiones traducidas de los banners y capturas de pantalla así que este puede ser un punto que te haga destacar sobre el resto.

Banners

• banner-772x250.png (banner por defecto)
• banner-772x250-es_ES.png (banner en español)
• banner-1544x500-es_ES.png (banner retina en español)

Puedes incluir texto en tu idioma o mostrar la interfaz del plugin traducida. Cuando un usuario visite WordPress.org en español, verá automáticamente tu banner en español.

Formato del locale

Puedes usar el código completo (es_ES, fr_FR, de_DE) o el código corto del idioma (es, fr, de). Si WordPress no encuentra la versión específica es_ES, buscará la versión es.

Estrategia realista

No tienes que traducir a 30 idiomas el primer día. Empieza por:

1. Tu idioma nativo (si no es inglés), pues ese lo puedes traducir tú mismo o incluso subir directamente los ficheros .pot, .po y .mo.
2. Inglés (para el mercado internacional) por defecto, que además es lo esperado.
3. Los 2-3 idiomas más hablados para tu nicho y público objetivo.

Traducciones colaborativas

Una vez publicado, la comunidad de WordPress puede contribuir con traducciones en translate.wordpress.org. Pero ofrecer capturas de pantalla y banners en otros locale es algo que SOLO TÚ puedes hacer, y marca una diferencia enorme.

Ejemplo práctico

Si creas un plugin para WooCommerce y tu público objetivo incluye España, México y Argentina:

• Traduce el readme.txt al español del locale de España.
• Añade screenshot-1-es_ES.png mostrando la interfaz en español.
• Diseña banner-772x250-es_ES.png con texto o elementos que resuenen con hispanohablantes.

Y dirás ¿por qué no lo haces usando el es_AR o es_MX, pues por la peculiaridad de que en casi toda Hispanoamérica la traducción más utilizada es la del español de España (es_ES), al ser la que siempre está más completa.

Cuando un usuario busque en WordPress.org con el sitio en español, verá tu plugin completamente adaptado. Mientras tus competidores muestran capturas en inglés, tú muestras exactamente cómo se verá en su idioma. ¿Cuál crees que instalarán?

Dato importante: Los assets localizados se guardan en la carpeta /assets de tu SVN con el formato de nombre descrito. WordPress.org se encarga automáticamente de mostrar la versión correcta según el idioma del usuario.

Optimización para búsquedas en WordPress.org

El algoritmo de búsqueda de WordPress.org es público y conocido, pero por algún motivo no le dedicamos unos segundos a que nuestros plugins aprovechen sus algoritmos.

Esto es lo que más pesa

1. Título del plugin (lo más importante)
2. Descripción corta
3. Tags
4. Soporte activo (responder y resolver hilos de soporte)
5. Actualizaciones recientes (mínimo cada 6 meses)
6. Compatibilidad actualizada

Estrategia de palabras clave

• Investiga qué términos busca la gente. Prueba búsquedas en WordPress.org y mira qué plugins salen primero.
• Usa Google Trends o herramientas similares para analizar el volumen de búsquedas según el texto que uses.
• Incluye esas palabras en título, descripción y tags.
• Pero hazlo natural, sin spam de keywords forzadas.

El soporte es tu mejor herramienta de marketing

Responder rápido y resolver dudas en el foro de soporte tiene dos efectos:

1. Mejora tu ranking en búsquedas (el algoritmo lo tiene en cuenta).
2. Genera confianza. Los usuarios leen los hilos de soporte antes de instalar.

Buenas prácticas

• Responde en menos de 24-48 horas.
• Sé amable incluso con usuarios difíciles.
• Si entiendes varios idiomas contesta a cada usuario en su lengua.
• Marca los hilos como «resueltos» cuando termines (muchos desarrolladores olvidan esto y les penaliza).
• Si no puedes solucionar algo, sé honesto y explica por qué.
• Los hilos sin respuesta o sin resolver cuentan en tu contra.

Actualizaciones constantes (aunque sean pequeñas)

Un plugin sin actualizaciones desde hace más de 6 meses pierde posiciones rápidamente en las búsquedas.

Estrategia

• Actualiza cada 3-4 meses como mínimo.
• No hace falta que sean cambios grandes: mejoras de rendimiento, correcciones menores, actualización de compatibilidad.
• Documenta cada cambio en el changelog.
• Cada actualización te da una oportunidad de que WordPress.org muestre tu plugin como «Actualizado recientemente».

El equilibrio entre gratis y premium: cómo no caer en el lado oscuro

Este es uno de los temas más delicados en WordPress.org y afecta directamente a tu reputación y número de usuarios.

El problema del freemium tóxico

Cada vez hay más plugins en el directorio que son meros escaparates de versiones premium.

Diría que es algo frustrante, pero en realidad es una mierda muy grande, por varios motivos:

• Usuarios que instalan esperando una solución y encuentran un anuncio.
• Funciones básicas bloqueadas tras un muro de pago.
• Interfaces llenas de banners de «Upgrade to PRO».
• Plugins que técnicamente funcionan pero son inútiles sin pagar.

¿Qué dicen las reglas de WordPress.org?

Las reglas sobre el tema de plugins freemium en WordPress.org son el perfecto ejemplo de normas escritas que nadie cumple, ni siquiera quien las redactó.

• El código del plugin gratuito debe estar 100% disponible.
  Aunque las funcionalidades gratuitas no hagan nada o casi nada
• No puedes bloquear funcionalidades mediante servicios externos de validación de licencias como único propósito.
  No las bloquean, directamente no tiene casi nada potable disponible si no te conectas, y de hecho hay muchos que ni siquiera funcionan, como por ejemplo el plugin instalado por defecto Akismet, del propio creador de WordPress. Ahí, dando ejemplo)
• Puedes ofrecer servicios externos (SaaS) siempre que estén documentados.
  Casi siempre está escondido en la última línea del readme
• Puedes mencionar versiones premium, pero sin secuestrar la experiencia de usuario.
  Esto se lo saltan casi todos los que ofrecen versiones premium, y es una puta vergüenza

Estrategias que funcionan (y son éticas)

El modelo gratis total + extras premium

• Versión gratuita: resuelve el problema principal completamente.
• Versión premium: añade funcionalidades avanzadas o integraciones extra.
• Ejemplo: un plugin de formularios que funciona perfecto gratis, y premium añade integraciones con CRMs o lógica condicional avanzada.

El modelo core gratis + extensiones premium

• El plugin base es totalmente funcional.
• Las extensiones amplían funcionalidades para casos de uso específicos.
• Se venden fuera de WordPress.org.
• Ejemplo: WooCommerce funciona perfectamente gratis, las extensiones se venden aparte.

El modelo gratis total + soporte premium

• Plugin 100% gratis y completo.
• Cobras por soporte prioritario, instalación, personalización.
• No molestas a usuarios que solo quieren usar el plugin.

El modelo totalmente gratis

• El plugin es tu tarjeta de presentación.
• Monetizas ofreciendo servicios relacionados, consultoría, otros productos.
• Construyes reputación y comunidad.

Lo que NO debes hacer

• Plugin inútil sin actualización premium: Si todas las funciones útiles están bloqueadas, no publiques en WordPress.org. Es spam.
• Banners agresivos para actualizar: Un aviso discreto en la página de configuración está bien. Banners en cada página del admin, pop-ups, o notificaciones constantes NO.
• Falsas promesas en el readme: Si el 90% de lo que describes solo funciona en premium, estás engañando.
• Funciones demo: Permitir usar una función 5 veces y luego bloquearla es frustrante y genera malas reseñas.
• Ocultar que es freemium: Deja claro desde el readme qué es gratis y qué no.

Cómo comunicar – correctamente – que tienes una versión premium

En el readme, en sección aparte

== Free vs Premium ==

The free version includes:
- Feature A
- Feature B
- Feature C

The premium version adds:
- Advanced Feature D
- Integration with X
- Priority support

En el admin, discretamente

Un único enlace a «Upgrade», o pestaña «Premium Features» está bien. No invadas cada rincón del wp-admin o los usuarios te odiarán/emos.

En el texto, honesto

«Este plugin soluciona el problema X. Para usuarios avanzados que necesiten Y y Z, ofrecemos una versión premium.»

¿A que así se entiende de maravilla y no es ni mucho menos mala publicidad?

Por qué importa

Los usuarios están/mos cansados de «trial-ware» disfrazado de plugin gratuito. Si tu plugin gratis realmente resuelve algo útil:

• Tendrás mejores valoraciones.
• Más gente lo recomendará.
• Paradójicamente, más usuarios comprarán premium (porque confían en ti).
• Menos usuarios frustrados en el foro de soporte.

Ejemplo de buenas prácticas

Mira plugins establecidos como WooCommerce o SEOPress:

• La versión gratis es completamente funcional.
• Millones de usuarios nunca necesitan premium.
• Los que sí necesitan funciones avanzadas, entienden el valor y pagan gustosos.
• No hay sensación de «estafa» o muro de pago agresivo.

La pregunta clave

Antes de publicar, hazte esta pregunta honesta:

«Si yo fuera un usuario normal, ¿podría usar este plugin gratis para resolver mi problema, o me sentiría engañado?»

Si la respuesta es la segunda, replantea tu estrategia. Un plugin gratuito que da valor real es mejor marketing que un freemium agresivo que genera frustración.

Recuerda: WordPress.org es una comunidad, no solo un canal de ventas. Los desarrolladores que aportan valor real son los que construyen reputación duradera.

Cosas del código que SÍ importan a los usuarios

Aunque los usuarios no vean el código, cómo organizas el plugin afecta a su percepción de calidad.

Velocidad de carga

Los plugins pesados que cargan scripts innecesarios en todas las páginas generan valoraciones negativas. Carga los recursos solo donde los necesite tu plugin.

Compatibilidad con PHP, WordPress y – si es el caso – WooCommerce

Indica claramente en el readme desde qué versión de PHP funciona (mínimo PHP 7.4 para buena compatibilidad). Igualmente, siempre comprueba que tu plugin sea compatible con las últimas versiones de WordPress, y si procede, también con las últimas de WooCommerce, añadiendo la tag correspondiente.

Traducciones

Prepara tu plugin para traducción desde el principio. Muchos usuarios buscan plugins en su idioma. No necesitas incluir load_plugin_textdomain() si tu plugin está en WordPress.org (desde WordPress 4.6 se carga automáticamente).

Después de publicar: difusión sin hacer spam

Una vez publicado, no esperes que la gente descubra tu plugin por su cuenta. Pero ojo, hay una línea fina entre promoción legítima y spam.

Lo que SÍ puedes hacer

• Mencionarlo en tus perfiles sociales (con enlace directo a WordPress.org).
• Escribir un artículo en tu blog explicando cómo usarlo.
• Responder en foros cuando alguien pregunte por una solución que tu plugin ofrece (sin spam, solo cuando sea relevante).
• Contactar con sitios de listados de plugins (como «Los mejores 10 plugins para X») si tu plugin encaja.
• Pedir reseñas a los usuarios que lo hayan probado y les haya servido.

Lo que NO debes hacer

• Llenar el readme de keywords repetidas.
• Usar tags de competidores.
• Crear cuentas falsas para dejar reseñas positivas.
• Spam en foros.

Revisa y mejora

No publiques tu plugin y te olvides, revisa periódicamente al menos estas cosillas:

• Descargas: ¿cuándo suben? ¿hay patrones?
• Búsquedas: ¿por qué términos te encuentran?
• Soporte: ¿qué preguntan más?
• Valoraciones: ¿qué critican o alaban?

Usa esta información para mejorar el readme, añadir características o crear nuevas versiones.

Casos reales de plugins con cosas bien y mal hechas

Veamos ejemplos concretos de cosas bien y mal hechas, y sus consecuencias. Y para no sacar los colores a nadie me pongo a mi mismo como ejemplo, que tengo para darme de bofetadas.

No Gutenberg (+10.000 instalaciones activas)

• Título claro que incluye «Disable Blocks Editor» y «Classic Editor»
• Resuelve un problema específico y frecuente.
• No intenta ser un «plugin completo para el editor».
• Readme directo: dice qué hace sin rodeos.

AI Share & Summarize (+100 instalaciones)

• Buen título descriptivo.
• Nicho específico (IA + compartir contenido).
• Oportunidad de mejora: podría tener mejor presencia visual con capturas de pantalla más destacadas.

Easy Actions Scheduler Cleaner (menos de 10 instalaciones)

• Muy específico, resuelve un problema concreto.
• Buen nombre descriptivo.
• Oportunidad de mejora: el problema que resuelve no es tan conocido; el readme podría explicar mejor POR QUÉ alguien necesita limpiar el Actions Scheduler.

Errores comunes a evitar

1. Título genérico sin palabras clave.
2. Readme sin estructura clara ni viñetas.
3. Sin imágenes o con imágenes de baja calidad.
4. No responder en el foro de soporte.
5. Descripciones vagas: «mejora tu web» no dice nada
6. Olvidar actualizar el «Tested up to»
7. Competir con gigantes en lugar de buscar nichos
8. No revisar qué busca la gente realmente

Resumen: lista de tareas

Por si ha sido de tu interés este asunto, y ya que te has puesto, ya que te has pegado la currada de crear tu plugin, subirlo a WordPress.org, pasar el proceso de revisión y estar con el cuajo suficiente como para mantenerlo y ayudar a otros, qué menos que tener a mano una lista de cosillas que no debes/mos olvidar.

Antes de publicar el plugin

• Asegúrate de que resuelves un problema real.
• Elige un título con 2-5 palabras que describan el problema y/o la solución.
• Escribe un readme claro con short description que complemente el título.
• Cuando puedas (no es imprescindible nada más subirlo) crea el icono y unos banner atractivos.
• Añade al menos 3 capturas de pantalla que muestren claramente lo que hace el plugin y cómo lo hace.
• Selecciona las 5 tags más relevantes.

Después de publicar el plugin

• Responde el soporte en menos de 48h y marca como resuelto.
• Actualiza cada 3-4 meses mínimo.
• Mantén actualizado el «Tested up to»
• Analiza qué funciona y qué no.
• Ajusta el readme y la estrategia según los resultados.

Resumiendo

Conseguir usuarios para tu plugin en WordPress.org no es cuestión de magia ni de suerte (bueno suerte sí, un poco), sino una combinación de: resolver problemas reales, presentar tu solución de forma clara, mantener el plugin actualizado y atender a los usuarios. La mayoría de desarrolladores fallan/mos en la presentación, no en el código.

Dedica algo tiempo al readme, las imágenes y el título, que no es algo que tengas que hacer todos los días, y son tu escaparate. Si un usuario no entiende en 5 segundos qué hace tu plugin y por qué lo necesita, buscará otro.

Y recuerda, lo que yo creo que es lo más importante:

Merece más la pena ofrecer el mejor plugin que resuelve un problema pequeño que un plugin mediocre intentando resolver todos los problemas del mundo.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!