Seo en Laravel - Optimizando los archivos JavaScript en un blog

▶

Cuando llegué por primera vez al mundo del “SEO en Laravel”, pensé que la cosa iba más de contenido y menos de código. Error. El SEO técnico puede elevar o hundir un proyecto, especialmente cuando trabajas con frameworks como Laravel, donde el rendimiento, la estructura del HTML y la forma en que cargas recursos pueden cambiar por completo tu posición en las SERP. No exagero: pequeños detalles técnicos pueden darte un empujón brutal… o quitarte 40 puntos de PageSpeed de un día para otro.

En mi caso, arranqué con un puntaje de 37 en PageSpeed en algunas publicaciones del blog. Sí, 37… casi que me daba vergüenza. Y ojo: no era porque Laravel fuera lento. El problema era mío: scripts innecesarios, iframes asesinos, imágenes mal optimizadas y un JavaScript que parecía salido de una bodega olvidada.

A lo largo de este artículo te voy a contar todo lo que aprendí optimizando mi sitio, cómo llegué a 100 de rendimiento, qué cosas aún pueden mejorarse y cómo evitar que tu proyecto Laravel termine ahogado por YouTube, Facebook, GTM o cualquier otro script que decides agregar “por si acaso”.

No te voy a dar teoría reciclada: aquí solo hay práctica, sudor, pruebas, errores y resultados reales.

Bases del SEO en Laravel: Lo esencial que sí impacta

Antes de entrar en los hacks técnicos, ajustes avanzados y trucos de rendimiento, el SEO en Laravel tiene tres pilares básicos: URLs limpias, metaetiquetas bien generadas y una estructura HTML coherente.

URLs limpias, enrutamiento y estructura semántica

Laravel nos da una base fantástica con su sistema de rutas. Crear URLs limpias, predecibles, cortas y con palabras clave es tan fácil como escribir:

Route::get('/blog/{slug}', [PostController::class, 'show']);

Esto permite una estructura clara, esencial para la indexación. Pero la clave no es solo crear rutas SEO-friendly, sino mantener una estructura de encabezados correcta en las vistas Blade.

Confieso que, durante un tiempo, tenía un H1, luego un H3… y luego volvía a un H2. PageSpeed me lo marcaba como error de accesibilidad, y también afecta el SEO. Desde que corregí esto, la semántica de mis páginas mejoró muchísimo.

Metaetiquetas dinámicas con Blade y helpers SEO

Laravel y Blade facilitan algo que muchos CMS complican: metaetiquetas dinámicas. Si tus títulos, descripciones y OpenGraph se generan en base al contenido, Google te recompensa porque entiende mejor la intención de cada página.

Yo trabajo así:

<title>{{ $post->title }}</title>
<meta name="description" content="{{ $post->description }}">
<link rel="canonical" href="{{ url()->current() }}">

Sencillo, limpio y funcional.

Open Graph, Twitter Cards y canónicas sin romper tu arquitectura

La mayoría de competidores olvidan que los motores sociales también influyen en el SEO indirecto. Tener OG tags bien generadas aumenta el CTR desde redes, y eso termina impulsando la autoridad de tu dominio. No es magia; es coherencia semántica.

Optimización extrema de rendimiento en Laravel (el verdadero factor SEO)

Aquí es donde Laravel brilla… o donde puedes tirarlo por un barranco si no cuidas lo que cargas. Google es claro: rendimiento = SEO. PageSpeed evalúa JavaScript, CSS, imágenes, layout, estabilidad visual, accesibilidad y eficiencia del HTML.

Cómo analizar qué JavaScript bloquea tu página

Yo siempre empiezo abriendo DevTools → pestaña Network → filtro .js.
Cuando hice esto con mi blog por primera vez, me encontré scripts que ni sabía que estaban cargando: GTM, Google Ads, Facebook Pixel… todos ejecutándose ANTES del contenido principal. Para una web donde estos scripts no son críticos, es un crimen.

Los retrasé todos. Y sí, solo ese cambio mejoró notablemente el tiempo de interacción.

Modularización del JavaScript: de un blog.js gigante a scripts ligeros

Tenía un blog.js enorme donde metí todo lo que necesitaba “en algún momento”. Error de novato. Con el tiempo lo dividí, eliminé dependencias y dejé solo las funciones necesarias. Hoy pesa menos de 300 líneas y se ejecuta bajo demanda.

Por ejemplo, eliminé completamente Axios; con fetch() resolví todas mis necesidades. Esta decisión no solo ahorra peso, sino que reduce dependencias innecesarias.

Eliminando lo que sobra: scripts del dashboard, plugins y recursos fantasma

Algo que me marcó PageSpeed era que se estaban cargando scripts del panel de administración en el frontend. Esto no tiene sentido, pero a veces pasa con paquetes o configuraciones mal heredadas.

Los eliminé todos. Resultado: páginas más rápidas y un DOM más limpio.

Carga diferida de JS y recursos críticos

• Mi regla es simple:
• CSS crítico: carga inmediata.
• JavaScript: bajo demanda.
• Terceros: lo más tarde posible.

Con eso solo ya ganas puntos importantes.

El caso YouTube: Cómo un solo iframe puede destruir tu SEO

▶

Aquí viene el gran drama. El iframe nativo de YouTube es un veneno, así, sin rodeos. Si lo incrustas tal cual te lo da YouTube, añades 500 KB de JavaScript innecesario que se ejecuta ANTES de que el usuario haga clic.

Entonces, quiero analizar qué JavaScript está cargando en mi página. Para ello, me dirijo a la sección de herramientas del desarrollador, específicamente a la pestaña de Network, y filtro por .js. Al recargar la página, puedo ver claramente los scripts cargados, y veremos que el de JS es una parte CRITICA, ya que carga demasiados recursos, rentalizando la carga de toda la web.

Cómo Pasé de un Rendimiento de 37 a 100 en PageSpeed: El Problema del <iframe>

En este y en los próximos videos te voy a hablar un poco de cómo pasé de tener un rendimiento de 37 en mis publicaciones, a simplemente alcanzar 100. Lo cual, sinceramente, aún me sorprende bastante, ya que todavía tengo algunas cositas que corregir. Por lo tanto, aunque la métrica ahora sea perfecta, el sitio no lo es del todo. Aún tengo detalles por mejorar, como lo tengo anotado por aquí, pero en fin... te voy a ir comentando de todo un poco.

En este primer video, quiero enfocarme únicamente en el bendito <iframe> de YouTube, que ha sido un verdadero veneno para el rendimiento.

El Dilema del Video Incrustado en el Blog

Si tú tienes un blog, seguramente ya te han comentado que debes compartir tanto texto como video, sobre todo si haces contenido mixto. Es decir, creas un video y luego haces un artículo, o viceversa. Lo ideal es que ambos se presenten en la misma publicación: el video arriba y el texto abajo. De esta forma estás potenciando tu contenido al ofrecer dos formatos distintos.

Hasta ahí, todo bien.
El problema viene cuando decides incrustar el video directamente con el <iframe> de YouTube, que es una verdadera porquería en términos de rendimiento.

Ese fue el cáncer que tenía en mi blog, así que quiero hablarte un poco sobre eso.

Por qué el iframe nativo de YouTube es un veneno para PageSpeed

Cuando analicé mis publicaciones con DevTools, noté que el iframe cargaba un montón de scripts de YouTube, incluso si el usuario ni siquiera veía el video. Eso mataba mi LCP.

Fue uno de los grandes responsables del famoso “37” que tenía al inicio.

Solución: miniatura WebP + reproductor bajo demanda

Lo que hago ahora es súper simple:

• Cargo una imagen WebP (local, ligera).
• Cuando el usuario hace clic, recién ahí cargo el iframe real.
• El video aparece como si siempre hubiese estado ahí.

Resultado:

• carga ultrarrápida
• cero JS de YouTube bloqueante
• experiencia limpia

Lo más irónico es que YouTube te da un JPG como miniatura… pero Google te penaliza si no usas WebP. Excelente.

Cómo recuperar los datos enriquecidos con JSON-LD (VideoObject) - Datos Estructurados

Si haces eliminación del iframe nativo, Google ya no detecta automáticamente tu video. La solución: usar JSON-LD.

Yo genero este bloque dinámicamente:

{
 "@context": "https://schema.org",
 "@type": "VideoObject",
 "name": "{{ $post->title }}",
 "description": "{{ $post->description }}",
 "thumbnailUrl": "mi-miniatura.webp",
 "uploadDate": "{{ $post->date }}",
 "embedUrl": "https://www.youtube.com/embed/{{ $videoId }}",
 "publisher": {
   "@type": "Organization",
   "name": "Desarrollo Libre"
 }
}

En el código fuente, puedes ver que uso un script donde especifico datos como:

• Título del video
• Descripción (la misma que la del post)
• Fecha de publicación
• Nombre del autor (en mi caso, yo mismo o “Desarrollo Libre”)
• Logo del canal
• URL del video en YouTube

Desde que agregué esto, Google volvió a entender mis videos sin penalizar el rendimiento.

¿Plugins como lite-youtube-embed?

El problema es que te casas con una sintaxis específica del plugin, como por ejemplo:

<lite-youtube videoid="TuIDDeVideo"></lite-youtube>

Y eso es justo lo que yo no quería. Prefiero mantener el contenido como lo hace todo el mundo —usando <iframe>— para luego procesarlo internamente. Pero si tú quieres ir por la vía del plugin, también es válido.

Identificación de mis JavaScript

En este punto, tenemos claro los scripts que no forman parte de la web, como los de pixel de Facebook o el ADS de Google, también conocemos otros recursos como el de Youtube que aunque no forman parte de la web, si son necesarios para tener un recurso más interesante.

Lo siguiente que buscamos, es que podemos optimizar de nuestros propios  archivos JS. En este caso, son dos:

• highlight.js
• blog.js

Optimización de imágenes, multimedia y DOM

Estos dos son de mi autoría. Ya esto es una mejora, porque antes tenía todo en un solo archivo, el famoso blog.js. Este incluía de todo. En base a recomendaciones, decidí dividirlos en módulos más pequeños.

También estoy eliminando dependencias que ya no necesito. Por ejemplo, Axios: en el blog solo hago unas pocas peticiones, y he migrado la mayoría a fetch. Puede que todavía quede algo por allí, pero poco a poco estoy ordenando todo.

Reemplazo de Axios y otros scripts

Ya eliminé Axios por completo. También consideré quitar Alpine, pero pesa tan poco que por ahora lo voy a dejar.

Otro script que estoy evaluando es el del plugin de highlight.js. Este es fundamental para mí, ya que da formato al código en los artículos. Aunque no tengo un ejemplo aquí visible, básicamente lo que hace es detectar bloques pre y aplicarles un formato visual, separándolos por tokens para estilizar el código.

Organización del código y carga condicional

Lo que estoy haciendo es organizar el código mejor. Por ejemplo, tengo el highlight.js dividido: su CSS está en el layout principal, y el JS lo cargo solo cuando es necesario, bajo una condición específica. Esa lógica te la explicaré en un próximo video.

El archivo blog.js ahora solo contiene las funciones mínimas: búsquedas y peticiones locales. Tiene menos de 300 líneas y planeo optimizarlo aún más. Solo conserva lo esencial.

TRUCAZO para el SEO en Laravel, Carga Diferida y Pre Render del contenido

▶

Te explicaba cómo pasé de un puntaje de 50 a 73 en PageSpeed, simplemente cambiando el bendito iframe de YouTube. Esto era lo que tenía inicialmente, y fíjate que cuando lo cambio, ya tengo aquí 73. Ahora voy a continuar la explicación desde ese punto y mostrarte cómo llegué hasta los 100, con los cambios que realicé.

Ejemplo real: cómo pasé de 37 a 100 en PageSpeed

Aprovecho también para comentarte que este material formará parte de un curso que voy a crear más adelante. Actualmente estoy trabajando en mi tienda en línea —a la fecha de grabación—, pero luego haré otro curso sobre cómo crear un blog bien optimizado, explicando todos estos detalles y algunas cosas más.

Este es el punto donde todo encaja. El camino fue más o menos así:

1. Eliminé Axios

2. Dividí mi JS

3. Eliminé scripts del dashboard

4. Implementé thumbnails WebP para YouTube

5. Añadí JSON-LD para recuperar SEO perdido

6. Mejoré accesibilidad

7. Reorganicé encabezados

8. Integré carga diferida para Alpine, highlight.js y otros scripts

SEO técnico en Laravel: tareas esenciales que Google sí evalúa

Mejorar la accesibilidad, title, alt y derivados

También hice ajustes en las imágenes, asegurándome de colocar el atributo alt con una descripción adecuada. Y algo muy importante: respetar la jerarquía de encabezados. Si colocas un H1, el siguiente debe ser un H2, luego H3, y así sucesivamente. No deberías pasar de un H1 a un H3 directamente, porque se rompe la lógica del contenido. Eso era uno de los detalles que me estaban observando.

Laravel facilita aplicar SEO técnico real si conoces dónde tocar.

Sitemap XML con Spatie

Es práctico, simple y totalmente automático.

robots.txt, canónicas e indexabilidad

Laravel no toca esto por defecto, pero crear un robots.txt dinámico es sencillo. Las URLs canónicas deben generarse automáticamente según la ruta.

Seguridad y HTTPS

HTTPS es obligatorio. Laravel facilita todo el manejo de CSRF, headers seguros y buenas prácticas.

Accesibilidad y semántica

A partir de ahí, el resto de los cambios se centraron en hacer la carga más eficiente. Eso incluía cosas como mejorar la accesibilidad, por ejemplo, colocando atributos especiales a los botones para indicar su función. Esto sirve especialmente para lectores de pantalla, como los que usan personas con discapacidad visual, para que entiendan qué hace cada botón:

Los botones no tienen nombres accesibles
A continuación se indican consejos para mejorar la semántica de los controles de tu aplicación. Estos consejos pueden mejorar la experiencia de los usuarios de tecnologías de asistencia, como los lectores de pantalla.

<button aria-label="Cerrar ventana">
   <svg><!-- ícono de cerrar --></svg>
</button>

Los lectores de pantalla agradecen esto, y Google también.

Paquetes SEO recomendados para proyectos Laravel

• spatie/laravel-sitemap → sitemap.xml automático
• spatie/schema-org → JSON-LD limpio
• artesaos/seotools → metaetiquetas completas
• laravelium/sitemap → alternativa ligera

Todos estos ayudan, pero ninguno sustituye optimizar JS, imágenes y HTML.

Optimizar recursos bloqueantes

Además, optimicé la respuesta del servidor. Aunque el cambio del iframe ayudó mucho, también empecé a remover todo el JavaScript innecesario. Había cosas cargándose desde el dashboard, sin sentido. Todo eso lo eliminé.

Reducción de JavaScript y código más limpio

El JavaScript que estaba cargando afectaba bastante. Aquí puedes ver lo que me estaba tomando el iframe de YouTube: una barbaridad. Y todos estos pequeños cambios afectan directamente cómo se renderiza la página.

A medida que resuelves esos problemas, la carga mejora, el servidor responde más rápido, y todo se procesa con más eficiencia. Por eso, haciendo pocos cambios estratégicos, la web evolucionó bastante.

El problema del DOM excesivo

Uno de los aspectos que también me señalaba Google era el tamaño excesivo del DOM. Esto es porque, por ejemplo, en mi contenido tengo dos tipos principales: uno con el video de YouTube y su transcripción, y otro con los cursos.

Cuando abres un curso, el documento es largo porque contiene todas las secciones del curso con su descripción. Es decir, coloco toda esa estructura dentro del HTML para que Google entienda qué hace cada cosa. Por eso el DOM es tan largo.

Esto viene directamente de mi plataforma de cursos, donde cada sección tiene sus clases. Simplemente copié esa estructura a la publicación del blog. Así que, aunque sea largo, tiene sentido y es contenido útil.

Problemas de formato y accesibilidad

Hay algunos detalles visuales que también debo mejorar. Por ejemplo, algunos contrastes son muy fuertes. Le coloqué un fondo más oscuro, pero tal vez es demasiado. También debo reorganizar el listado para que los posts recientes aparezcan primero.

Y algo curioso: cuando utilizo las imágenes de YouTube, estas devuelven un JPG, no un WebP, que es lo que Google prefiere. Y eso que si tú subes una imagen a YouTube y haces clic derecho para descargarla, muchas veces obtienes un WebP. No sé por qué no lo hacen por defecto... parece que lo hacen a propósito para complicarnos la vida.

Reducción de JavaScript: más a fondo
Volviendo a los aspectos clave: reducir JavaScript fue esencial. También cuidar los nombres y atributos. Por ejemplo, las imágenes deben tener su atributo alt, y los botones deben tener su aria-label, que ni conocía, pero que sirve para indicar qué hace cada botón.

Lo que más me importa explicarte es cómo dejé todo lo más natural posible. Si una publicación tiene un video de YouTube, simplemente coloco el iframe y listo.

Código fuente y Highlight.js

Este blog es para programadores, así que obviamente hay partes de código. Estoy trabajando en paralelo con los libros, que tienen mucho código. Para eso uso highlight.js, que estiliza el código y lo muestra bonito.

El problema es que cuando tienes un libro con 300 páginas, el plugin se vuelve pesado. En algún punto deja de funcionar o se ralentiza mucho. Eso también afecta la carga de la página.

Por eso hice algo clave: procesar el contenido una sola vez y guardarlo en un campo llamado final_content. Eso significa que el Highlight.js solo se ejecuta una vez, y luego ya no se necesita. Así me ahorro toda la carga del plugin.

Alpine.js y scripts mínimos

Otra parte que optimicé fue la carga de scripts. Uso Alpine.js para el menú hamburguesa y botones de compartir. Pero aunque pesa poco (unos 8KB), decidí también retrasar su carga.

¿Qué es lo mínimo que necesita cargar mi web? El CSS, sin duda. El HTML solo no basta. También el CSS del plugin que estiliza el código. A Google no le gustan los cambios bruscos de estilo, por eso ese CSS debe ir cargado desde el principio.

Errores comunes que arruinan el SEO en Laravel

• Cargar GTM, Ads o Facebook Pixel demasiado temprano.
• Saltar de un H1 a un H3 sin pasar por el H2.
• Incrustar videos sin optimizar.
• Dejar scripts repetidos o innecesarios.
• No controlar atributos alt ni aria-label.
• Servir imágenes pesadas o sin WebP.

Laravel SEO, algunos paquetes para generar meta etiquetas

▶

Existen múltiples paquetes para generar etiquetas SEO para Laravel, esto es estupendo ya hay ciertas partes de la aplicación que es necesario devolver algunas etiquetas tipo met justamente donde lo necesitamos, sin preocuparnos de si los nombres de estas etiquetas son correctas o no, ya las genera el paquete por nosotros:

SEOTools 

Este es un paquete que permite generar etiquetas meta fácilmente mediante el uso de métodos:

https://github.com/artesaos/seotools

$ composer require artesaos/seotools

Con esto, ya podemos emplear métodos para generar las etiquetas como:

SEOTools::setTitle("Latest posts");
SEOTools::opengraph()->addProperty('type', 'articles');
SEOTools::twitter()->setSite('@LibreDesarrollo');
SEOTools::jsonLd()->addImage(URL::to('/public/images/logo/logo.png'));
SEOTools::setDescription("Here you will find the latest posts that I have uploaded to my blog.");

Desde la vista:

{!! SEO::generate() !!}

<!-- MINIFIED -->
{!! SEO::generate(true) !!}

Y tenemos:

<title>Latest posts</title>
<meta name="description" content="Here you will find the latest posts that I have uploaded to my blog.">
<meta property="og:title" content="Latest posts"><meta property="og:type" content="articles">
<meta property="og:description" content="Here you will find the latest posts that I have uploaded to my blog.">
<meta name="twitter:title" content="Latest posts"><meta name="twitter:site" content="@LibreDesarrollo">
<meta name="twitter:description" content="Here you will find the latest posts that I have uploaded to my blog.">
<script type="application/ld+json">{"@context":"https://schema.org","@type":"WebPage","name":"Últimas publicaciones","description":"Here you will find the latest posts that I have uploaded to my blog."}</script>

Para personalizar el paquete como valores por defecto o sufijos en el título, debes de publicar el archivo de configuración:

$ php artisan vendor:publish --provider="Artesaos\SEOTools\Providers\SEOToolsServiceProvider"

Laravel SEO

Este paquete genera metaetiquetas empleadas para el SEO:

• Etiqueta de title (con sufijo para todo el sitio)
• Metaetiquetas (author, description, image, robots, etc.)
• Etiquetas OpenGraph (Facebook, LinkedIn, etc.)
• Etiquetas de Twitter
• Datos estructurados (artículo y ruta de navegación)
• Favicon
• Etiqueta de robots

https://github.com/ralphjsmit/laravel-seo

$ composer require ralphjsmit/laravel-seo

Con esto, ya podemos emplear métodos para generar las etiquetas como:

$post = Post::find(1);

$post->seo->update([
   'title' => 'My great post',
   'description' => 'This great post will enhance your live.',
]);

Desde la vista:

{!! seo()->for($post) !!}

Hay varias otras configuraciones que puedes encontrar en la documentación oficial.

Paquetes de SEO en Laravel

Tres paquetes POTENTES para el SEO

• El primero es Artisa SEO Tools.
• El segundo es Ralph J. Smith Laravel SEO.
• El tercero es Laravel SEO Scanner.

Luego, ejecutaremos el scanner en dos demos separadas basadas en los dos primeros paquetes.

1. Artisa SEO Tools

El primer paquete, SEO Tools, funciona así: tenemos una página demo simple y lo que hace es que, si inspeccionamos un post en el código fuente, veremos etiquetas como meta description, meta Twitter, title, entre otras.

Para poblar estos datos desde la base de datos, creé un panel de administración con Filament dentro del mismo proyecto. Por ejemplo, podemos llenar title, description y author para un post, guardar los cambios y en la base de datos se verá reflejado en la tabla que creé específicamente para SEO, fuera del paquete.

Al refrescar la página, veremos los titles y metas en el código fuente, incluyendo OG title y OG description.

Además, se puede configurar valores por defecto a través de un archivo de configuración, incluyendo title, Open Graph, Twitter, entre otros.

Este paquete es antiguo (con commits de hace nueve años), pero todavía es compatible con Laravel 12. La última actualización del 14 de marzo adaptó el paquete para esta versión de Laravel.

2. Ralph J. Smith Laravel SEO

El segundo paquete es Ralph J. Smith Laravel SEO. Ralph es muy activo en la comunidad de Filament, y por eso parte de este paquete incluye funcionalidades para Filament.

En su documentación principal, indica que en el Blade solo necesitamos renderizar SEO para un post, y para obtener los datos del modelo, se usa hasSEO en el modelo Eloquent. Esto añade automáticamente la relación en la base de datos, a diferencia del primer paquete, donde creamos manualmente la relación.

Podemos cambiar title, description, etc., directamente desde el panel y los cambios se reflejan en la página, sin necesidad de manipular manualmente las relaciones como en el primer paquete.

Ambos paquetes permiten trabajar con meta tags, titles y etiquetas SEO en el HTML, lo cual sigue siendo relevante para SEO clásico en motores de búsqueda.

3. Laravel SEO Scanner

El tercer paquete es Laravel SEO Scanner, que permite escanear las páginas de tu sitio y revisar la configuración SEO según diferentes criterios.

Por ejemplo, tras instalarlo en el primer proyecto demo, ejecutamos seo:scan y obtenemos resultados como: 19 checks exitosos y 6 fallidos, indicando qué elementos faltan, como imagen de Open Graph, meta description, o keywords.

Conclusión

De los tres paquetes:

• Dos permiten configurar metadatos (Artisa SEO Tools y Ralph J. Smith SEO).
• Uno sirve para escanear las páginas (Laravel SEO Scanner).

Conclusión: Mantener un proyecto Laravel rápido, limpio y bien posicionado

El SEO en Laravel no es solo “agregar palabras clave”. Es un proceso técnico continuo. Debes revisar tus scripts, imágenes, estructura e integraciones. Los cambios pequeños suman, y a veces un solo iframe puede tumbarlo todo.

La clave está en:

• simplificar
• cargar solo lo esencial
• ordenar tu HTML
• monitorizar constantemente
• Si lo haces bien, puedes conseguir resultados como el salto que hice yo: de 37 a 100. Y lo más importante: mantener esa calidad a largo plazo.

Preguntas frecuentes sobre SEO en Laravel

• ¿Cómo mejorar el PageSpeed en Laravel?
  • En esta guía tienes pasos detallados para que puedas mejorar el SEO de tu web.
• ¿Qué paquetes SEO puedo usar?
  • Hay Muchos paquetes que puedes usar para el SEO, arriba te dí un listado.
• ¿Cómo optimizar YouTube en Laravel sin perder SEO?
  • Arriba te mostré como puedes generar un JSON especial para indicar cual es el contenido del vídeo.
• ¿Qué influye más: el contenido o el rendimiento?
  • Ambos elementos son importantes
• ¿Laravel es bueno para SEO?
  • Sí, si optimizas lo técnico