Eminence Astro Suite
- Astro
- TypeScript
- Cloudflare Workers
Why does this exist?
I kept repeating the same metadata configuration across my Astro projects. The SEO tools I found either missed things I needed or added too much fluff for the job.
I wanted something that leads you toward best practices without trapping you when a niche case needs something else. And I wanted the developer experience to be as good as Astro allows, not another layer to fight just to add a title or a social image.
What does it do?
Eminence Astro Suite brings page metadata and SEO-related files together in one Astro integration. You configure shared values once, and the components use them consistently across the site.
The integration creates the Vite virtual module the components need at runtime. It can generate icons from an SVG or a 512×512 image, and handles the flow for humans.txt, robots.txt, security.txt, and the sitemap through Astro’s original integration.
For most sites, using Head is enough. While you are building a page, you start with a title and description and get on with the actual page. When you need more, add Open Graph or JSON-LD to the layout props and voilà: it automatically fills in the site-wide tags you configured in the integration. It also generates the related files, so you avoid repeating information as much as possible.
It also deliberately limits its scope: it leaves out obsolete tags and outputs instead of collecting them just in case.
How did I build it?
I designed it integration-first, then built the components around that. The shared configuration lives in one place, so the components do not need to create their own defaults. The Vite virtual module connects those two parts and makes that configuration available at runtime.
The repository combines a documentation site with an Astro component package that is also an Astro integration. Rather than treating it as a set of disconnected tags, I wanted shared values, <head> components, and generated files to work as one flow.
Stack
- Astro
- TypeScript
- Cloudflare Workers for the documentation site
The hard parts
The first challenge was the project structure. Having a documentation site, an Astro component package, and an Astro integration in the same project makes development unlike a normal site or library. I had to be deliberate about where each responsibility belonged and how to test the whole thing without blurring the boundaries.
Then came choosing which tags to support. I read through every <head> tag, its attributes, why it exists, and whether it is still accurate or relevant. I spent hours researching, testing on real websites, and reviewing Google best practices, RFCs, MDN, and Next.js’s Metadata API to see how others approached it too. I documented the decision behind every tag in the documentation site. I did not want to present something outdated as a best practice. The lesson was that reducing surface area is not leaving features out for convenience; it is keeping an API I can stand behind.
I also went deep on file generation and TypeScript. I wanted as much autocomplete and type guidance as possible without adding unnecessary runtime checks that would hurt performance. That meant working through complex type edge cases and separating what can be guaranteed during development from what really needs validation at runtime.
Finally, the suite needed to be adapter-agnostic and work with both static sites and SSR. That constraint shaped the integration choices and reinforced that a platform convenience should not become a hidden dependency.
Impact
For now, I am the only person I know who uses it. It is in beta: it works as it is, but I still want to finish improvements and may make breaking changes before I consider it final.
It is open source. If you are also tired of repeating metadata configuration in Astro, you can try it, look through the approach, and open an issue when you find a case the suite does not handle well yet.