Download the PHP package backstage/laravel-seo-scanner without Composer

Laravel SEO Scanner

Nice to meet you, we're Backstage

Hi! We are a web development agency from Nijmegen in the Netherlands and we use Laravel for everything: advanced websites with a lot of bells and whitles and large web applications.

The Laravel tool to boost the SEO score of your web pages

Introduction

This package is your guidance to get a better SEO score on search engines. Laravel SEO Scanner scans your code and crawls the routes from your app. The package has 24 checks that will check on performance, configurations, use of meta tags and content quality.

Easily configure which routes to scan, exclude or include specific checks or even add your own checks! Completing checks will further improve the SEO score and thus increase the chance of ranking higher at the search engines.

• Minimum requirements
• Installation
• Available checks
  • Configuration
  • Content
  • Meta
  • Performance
• Usage
  • Running the scanner in a local environment
  • Scanning routes
  • Scanning a single route
  • Scanning routes in an SPA application
  • Throttling
  • Scanning large sites
  • Scan model urls
  • Saving scans into the database
  • Listening to events
  • Retrieving scans
  • Retrieving scores
  • Adding your own checks
• Testing
• Changelog
• Contributing
• Security Vulnerabilities
• Credits
• License

Minimum requirements

• PHP 8.2 or higher (8.2, 8.3, 8.4, 8.5)
• Laravel 12.0 or higher (12.x, 13.x)

Installation

You can install the package via composer:

If you want to scan pages that are rendered using Javascript, for example Vue or React, you need to install Puppeteer. You can install it using the following command:

If you want to know how to scan Javascript rendered pages, check out Puppeteer documentation.

Run the install command to publish the config file and run the migrations:

Or you can publish the config file and run the migrations manually:

Click here to see the config file.

Available checks

These checks are available in the package. You can add or remove checks in the config file. These checks are based on SEO best practices and if all checks are green, your website will have a good SEO score. If you want to add more checks, you can create a pull request.

Configuration

✅ The page does not have 'noindex' set.
✅ The page does not have 'nofollow' set.
✅ Robots.txt allows indexing.
✅ The site has a valid XML sitemap.

AI

✅ Known AI crawlers (GPTBot, ClaudeBot, PerplexityBot, ...) are not blocked in robots.txt.
✅ The site provides an llms.txt file.

Content

✅ The page has an H1 tag and if it is used only once per page.
✅ The page has a logical heading structure (no skipped heading levels).
✅ All links redirect to an url using HTTPS.
✅ Every image has an alt attribute.
✅ Every image has explicit width and height attributes (prevents layout shift).
✅ Images below the fold use lazy loading.
✅ The page contains no broken links.
✅ The page contains no broken images.
✅ Length of the content is at least 2100 characters.
✅ No more than 20% of the content contains too long sentences (more than 20 words).
✅ A minimum of 30% of the sentences contain a transition word or phrase.

Note: To change the locale of the transition words, you can publish the config file and change the locale in the config file. The default locale is null which uses the language of your app config. If set to nl or en, the transition words will be in Dutch or English. If you want to add more locales, you can create a pull request.

Meta

✅ The page has a meta description.
✅ The page title is not longer than 60 characters.
✅ The page has an Open Graph image.
✅ The page has a canonical URL.
✅ The page has complete Open Graph tags (og:title, og:description, og:url, og:type).
✅ The page has a Twitter card.
✅ The lang attribute is set on the html tag.
✅ The page has a valid viewport meta tag.
✅ The page has a character encoding declared.
✅ The page has a favicon.
✅ The page has valid hreflang annotations.
✅ The title contains one or more keywords.
✅ One or more keywords are present in the first paragraph.
✅ The page does not contain invalid HTML elements in the head section.
✅ The page contains structured data (JSON-LD).

Performance

✅ Time To First Byte (TTFB) is below 600ms.
✅ The page response returns a 200 status code.
✅ HTML is not larger than 100 KB.
✅ Images are not larger than 1 MB.
✅ Images use modern formats (WebP/AVIF).
✅ JavaScript files are not larger than 1 MB.
✅ CSS files are not larger than 15 KB.
✅ HTML is GZIP compressed.

Security

✅ The page does not use a long redirect chain.
✅ The page sets recommended security headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy).
✅ The page is served over HTTPS.

Usage

Running the scanner in a local environment

If you are using auto signed SSL certificates in your local development environment, you may want to disable the SSL certificate integrity check. You can do this by adding the following option to the http.options array in the config file:

It's also possible to pass custom headers to the http client. For example, if you want to set a custom user agent, you can add the following option to the http.headers array in the config file:

Scanning routes

By default, all GET routes will be checked for SEO. If you want to check the SEO score of a specific route, you can add the route name to the routes array in the config file. If you want to skip a route, you can add the route name to the exclude_routes array in the config file. If you don't want to check the SEO score of routes at all, you can set the check_routes option to false in the config file.

To check the SEO score of your routes, run the following command:

If you want to queue the scan and trigger it manually you can dispatch the 'Scan' job:

Scanning a single route

Want to get the score of a specific url? Run the following command:

Note: The command will only check the SEO score of the url and output the score in the CLI. It will not save the score to the database.

Output formats

Both seo:scan and seo:scan-url support a --format option. The default is the human-readable console output. Use --format=json to get structured JSON instead, which is ideal for CI pipelines or AI agents:

For seo:scan-url this outputs a single object; for seo:scan it outputs an array with one object per scanned URL. Each object looks like:

Scanning routes in an SPA application

If you have an SPA application, you can enable javascript rendering. This will use a headless browser to render the content. To enable javascript rendering, set the javascript option to true in the config file. You can also enable javascript rendering for a single route by adding the --javascript option to the command:

Note: This command will use Puppeteer to render the page. Make sure that you have Puppeteer installed on your system. You can install Puppeteer by running the following command: npm install puppeteer. At this moment it's only available when scanning single routes.

PageSpeed Insights (Core Web Vitals)

The package can pull the Google PageSpeed (Lighthouse) performance score and Core Web Vitals straight from the PageSpeed Insights API — no third-party package required. These checks are opt-in because they call an external API and are slower and rate-limited.

To enable them:

1. Request a free API key and set it (for example via .env):

2. Remove the PageSpeed checks you want to run from the exclude_checks array in config/seo.php:

You can configure the strategy (mobile or desktop) and request timeout under the pagespeed key in the config file. The three checks share a single API call per URL.

Throttling

If you want to throttle the requests, you can set the throttle option to true in the config file. You can also set the amount of requests per minute by setting the requests_per_minute option in the config file.

Scanning large sites

For large sites (think a webshop with thousands of product pages) a single synchronous run is slow and can hit the queue job timeout. The scanner can instead split the work into batched queue jobs and process them with multiple workers.

Run the scan as a batch of queued jobs:

This creates one scan record, splits the routes and model records into chunks, and dispatches them as a Bus::batch of ScanChunk jobs. When the batch finishes, the scan record is finalized (page count, failed checks, duration) and the ScanCompleted event is fired.

Memory stays flat regardless of how many model records you have: records are read in batches using lazyById() rather than loaded all at once. The batch size is controlled by chunk_size, which is also the number of pages each queue job scans:

Dispatch the jobs onto a dedicated queue so you can scale its workers independently:

Use a real queue connection (Redis, database, …) for parallel workers — the sync driver runs jobs inline and cannot run them in parallel.

Throttling across parallel workers. The throttle setting (see above) is enforced across all workers when scanning with --queue, using a cache-backed rate limiter. Because each job scans chunk_size pages, the limiter allows roughly requests_per_minute / chunk_size jobs per minute. For this to be shared between workers, use a shared cache store (Redis, Memcached or database) — not the array driver.

Scan model urls

When you have an application where you have a lot of pages which are related to a model, you can save the SEO score to the model. This way you can check the SEO score of a specific page and show it in your application.

For example, you have a BlogPost model which has a page for each content item:

1. Add the model to the models array in the config file.
2. Implement the SeoInterface in your model.
3. Add the HasSeoScore trait to your model.

Note: Please make sure that the model has a url attribute. This attribute will be used to check the SEO score of the model. Also check that the migrations are run. Otherwise the command will fail.

You can get the SEO score of a model by calling the seoScore() or seoScoreDetails() methods on the model. These methods are defined in the HasSeoScore trait and can be overridden by adding the modified method in your model.

To fill the database with the scores of all models, run the following command:

To get the SEO score(s) of a model, you have the following options:

1. Get the SEO scores of a single model from the database:

2. Run a SEO score check on a single model:

Saving scans into the database

When you want to save the SEO score to the database, you need to set the save option to true in the config file.

Optionally you can specify the database connection in the config file. If you want to save the SEO score to a model, you need to add the model to the models array in the config file. More information about this can be found in the Check the SEO score of a model section.

Pruning the database

Per default the package will prune the database from old scans. You can specify the number of days you want to keep the scans in the database. The default is 30 days.

If you want to prune the database, you need to add the prune command to your App\Console\Kernel:

Please refer to the Laravel documentation for more information about pruning the database.

Listening to events

When you run the seo:scan command, the package will fire an event to let you know it's finished. You can listen to this events and do something with the data. For example, you can send an email to the administrator when the SEO score of a page is below a certain threshold. Add the following code to your EventServiceProvider:

Retrieving scans

You can retrieve the scans from the database by using the SeoScan model. This model is used to save the scans to the database. You can use the SeoScan model to retrieve the scans from the database. For example:

Retrieving scores

You can retrieve the scores from the database by using the SeoScore model. This model is used to save the scores to the database. You can use the SeoScore model to retrieve the scores from the database. For example:

Adding your own checks

You can add your own checks to the package. To do this, you need to create a check class in your application.

1. Create a new class in your application which implements the Backstage\Seo\Interfaces\Check interface.
2. Add the Backstage\Seo\Traits\PerformCheck trait to your class.
3. Add the base path of your check classes to the check_paths array in the config file.

Example

In this example I make use of the symfony/dom-crawler package to crawl the HTML of a page as this is far more reliable than using preg_match for example. Feel free to use anything you want. The crawler is always passed to the check method, so you still need to define the $crawler parameter in your check method.

The config file:

Testing

Changelog

Please see CHANGELOG for more information on what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Security Vulnerabilities

Please review our security policy on how to report security vulnerabilities.

Credits

• Bas van Dinther
• Mark van Eijk
• All Contributors

License

The MIT License (MIT). Please see License File for more information.