Weave Code
Static Site Generator Laravel Package
statamic/static-site-generator
Laravel/Statamic addon that generates a static HTML version of your site with a single command. Configure routes, exclude pages, and deploy the output to any static host or CDN for fast, secure delivery—no PHP or database needed at runtime.
Generate static sites with Statamic.
Frequently asked questions about Static Site Generator
- How do I install and set up statamic/static-site-generator in a Laravel app?
- Install it with composer require statamic/ssg inside an existing Laravel/Statamic application. The service provider is auto-discovered, so you only need to publish config/ssg.php, set an absolute base URL, and run php please ssg:generate. There are no migrations, schema changes, or new production runtime services. It is an addon to Statamic, not a standalone static site generator, so it does nothing on a plain Laravel app.
- Does statamic/ssg 4.1.0 support Laravel 13?
- Yes. Version 4.1.0 adds Laravel 13 support and is a semver-minor release from 4.0.0 with no breaking changes, deprecations, or public API changes. The only other change is internal PHPUnit metadata migrated to attributes, which has zero consumer impact. Treat it as an unblocker in your framework upgrade workstream: any app pinned to SSG 4.0.x cannot move to Laravel 13.
- How does statamic/ssg generate the static HTML — does it crawl my site?
- It works by crawling your running site over HTTP and writing each response to disk. That means the build environment must actually serve the application correctly, with a resolvable host, the right APP_URL, correct base path, and absolute URLs that resolve. Size it as a build-pipeline dependency rather than a pure code dependency, and expect base URL mistakes to be the most common cause of broken links in the output.
- How do I configure which routes are generated or exclude pages?
- Routes and exclusions are controlled in config/ssg.php, where you define the paths to generate and any pages to leave out. Because discovery is crawl-based, routes that are never linked from anywhere can be missed, so seed them explicitly with include rules or a sitemap. Review the config as part of code review whenever new sections or collections are added.
- Do I need PHP and a database to serve the generated site in production?
- No. The output is plain static HTML, so production needs no PHP, no database, and no Statamic runtime. You can host it on any static host or CDN, which is where the speed and security benefits come from. The Laravel application is only required at build time and for editing content.
- What happens to forms, search, authentication, and other dynamic features on the static site?
- Request-time behavior is lost by design, so forms, server-side search, redirects middleware, auth, sessions, and personalization will not work unless you replace them. Plan for third-party form endpoints, a client-side or hosted search service, and explicit redirect rules at the host or CDN. Server-side redirects and response headers cannot be reproduced by static hosting, so audit those before committing to the delivery model.
- How do I deploy the static output and handle robots.txt, redirects, and 404 pages?
- Point your upload or sync step at the generated output directory and push it to your static host or CDN, then invalidate the cache. Copy pass-through files such as robots.txt, _redirects, and favicon.ico explicitly, and clean the destination directory before each build so removed pages stop being served. It is also worth running link validation against the built output before promoting a release.
- Does statamic/ssg support incremental builds, or is every page regenerated each time?
- Builds are full rebuilds, and duration scales roughly linearly with page count. There is no incremental mode, so large multisite or content-heavy installs should measure build time early. If rebuild frequency becomes a problem, schedule builds around content publishing rather than on every commit.
- Is statamic/ssg actively maintained? It shows zero dependents and only a few hundred stars.
- The dependent count is misleading here because this is an application-level addon, not a library other packages import, so the figure structurally understates adoption. The meaningful signals are first-party Statamic stewardship, an active 4.1.0 release, and roughly 252 stars as a floor on real-world use. Judge it on those rather than on Composer dependent counts.
- How does statamic/ssg compare to Astro, Hugo, or Next.js with a headless CMS?
- Those are separate platforms, so choosing them means a migration project with template rewrites and content migration, not a comparable line item. statamic/ssg reuses your existing Antlers templates, content model, routes, collections, taxonomies, and multisite setup, adding one Composer dependency and a config file. If you are already on Statamic, adoption is additive; if you are not on Statamic, this package is the wrong comparison entirely.
Weaver
How can I help you explore Laravel packages today?