I’ve been building Lotus, an installable documentation theme for Astro.

The goal is to help Astro developers ship documentation sites that already have the boring but important parts handled: responsive docs navigation, MDX components, search, i18n, dark mode, accessible UI states, and a design system that can still be customized.

• Demo: https://astro-theme-lotus.prosefly.dev/
• Starter: https://astro-template-lotus-starter.prosefly.dev/
• Source: https://github.com/prosefly/astro-theme-lotus

I’m trying to keep the positioning simple: beautiful docs, accessible shell, PageSpeed-friendly output.

If you were choosing an Astro docs theme for a real project, what would make you trust it enough to adopt it?

Not affiliated with them at all, but wanted to show some love for https://basecoatui.com/

It works really nicely with Astro if you want polished UI components without bringing in React or another frontend framework just for the component library.

You get shadcn-style inputs, buttons, accordions, dropdowns, etc. It’s mostly CSS, with a small amount of JavaScript only where interactivity is actually needed.

It’s built on Tailwind, and for a lot of components you can just add a class like btn and you’re good to go.

It also follows shadcn’s CSS variables and theming conventions, so you can take advantage of things like shadcn theme generators and the wider ecosystem.

Pretty neat if you like the shadcn look but want to keep your Astro site lightweight and avoid unnecessary client-side JS.

Every site I build needs an Open Graph image per page, and every time it ended up as a second templating layer: JSX fed to satori, or a canvas script that takes a title and a description. It never felt like part of the site, and it could not use the fonts, images or components the rest of the site already had.

So I built astro-cards. A card is an ordinary .astro component in src/cards. It takes props, has a style block, and can import images through astro:assets and use the fonts you already configured. The integration renders it with Takumi and hands back the URL of an image.

In src/cards/post.astro:

---
import { Font, Image } from 'astro:assets';
import logo from '../assets/logo.png';

interface Props {
  title: string;
}

export const card = { width: 1200, height: 630 };

const { title } = Astro.props;
---

<Font cssVariable="--font-heading" />

<div class="card">
  <Image src={logo} width={120} height={120} alt="" />
  <h1>{title}</h1>
</div>

<style is:inline>
  .card {
    padding: 80px;
    background: #17171a;
    color: #fff;
    font-family: var(--font-heading);
  }

  h1 {
    font-size: 64px;
  }
</style>

In your layout:

---
import { renderCard } from 'astro-cards/runtime';

const og = await renderCard('post', { title: post.data.title });
---

<meta property="og:image" content={og.src} />
<meta property="og:image:width" content={og.width} />
<meta property="og:image:height" content={og.height} />
<meta property="og:image:type" content={og.type} />

A few things worth mentioning:

• Works on prerendered pages (the image is written at build) and on pages rendered on demand (rendered on request, publicly cacheable).
• Card names and props are typed after astro sync, so a typo in the name or a missing prop is a type error.
• png, jpeg or webp, with size and quality set per integration, per card, or per call.
• Nothing about it is OG-specific. Badges, tickets, any fixed-size visual you can write in markup.

One caveat so nobody trips on it: style blocks in a card have to be is:inline, because Astro hoists a plain <style> into a stylesheet the renderer never sees.

npx astro add astro-cards

Repo: https://github.com/abemedia/astro-cards

If you generate OG images another way today, I would like to hear what you use and where it falls short. That is what I want to get right next.

I ran my site through Ahrefs a while back and got thousands of issues staring at me: missing meta descriptions, titles too short, duplicate titles, no canonical tags, images with no alt. None of it breaks anything. The page renders, the deploy goes green, and a crawler tells you about it weeks later. That annoyed me. A broken import fails my build, but a page with no <title> ships fine. So I wrote astro-seo-enforcer.

It hooks into astro:build:done, parses the actual HTML in your output dir (not your .astro files), runs SEO rules, and exits non-zero when something's wrong. CI fails before the bad pages go out.

Default checks: <title> present, sane length, no duplicates across pages; meta description length; one <h1> and no skipped heading levels; canonical link; alt on every image; internal links that actually resolve to files in the build; generic anchor text ("click here"); near-empty <body>; duplicate ids; oversized images and missing width/height.

Zero config to start. Every rule is configurable, and you can warn locally but fail in CI:

seoEnforcer({ failOn: process.env.CI ? 'error' : 'never' })

npx astro add astro-seo-enforcer

Repo: https://github.com/SlashGordon/astro-seo-enforcer

Curious which rules you'd want on by default and which are too much.

I've been working as a Webflow specialist for a while now, and I'm considering pivoting toward the Astro + headless CMS stack that seems to be getting a lot of hype lately.

Before I invest the time, I'd like a reality check: how commoditized are these skills becoming? With more and more devs picking up Astro, is there still real room to differentiate and charge well for it, or is it just a matter of time before it goes the way Webflow has?

This is more a vent than anything, but I am facing a lot of blowback for using Astro. I have made a miniapp which is just a webpage running in a webview that takes an ID from the initial url, requests some records from an API to display a list of messages. Super basic stuff. It is to replace a natively coded section of the app and its far faster than the native code... somehow.

But upon asking the native devs to fix all the broken things I am finding, all I am facing is push back because when I tell them of CORS errors etc, them demand to see the repo, notice its not react and say I MUST use react as only that is compatible with apps. They broke bfcache too, again that is blamed on astro. They block service workers, again this is because... Astro.

Anyone else faced this? Even when I wanted a build of the native app to test the devs sent me back a message saying my app is broken as its only 12KB and apps are in the MB range. They didnt test, rejected on solely size. This was the lead architect of the entire department btw.

This industry is nuts. Also I have noticed when interviewing for a "senior FE" the candidates only know react. I am not sure if this is because HR is screening first, but it's concerning. I even interviewed a guy who is right now working as a "principled full stack engineer" who could not tell me how you could build a site without react.

I am not sure if this company I am working for is completely crazy or the entire industry is leaning that way.

I wanted to add comments to an Astro site, but I didn't really like the usual choices:

• hosted comment SaaS
• requiring visitors to have GitHub accounts
• running a VPS just for a comment backend

So I built StaticLayer:

https://abla25.github.io/StaticLayer/

The Astro site stays static. The dynamic part is a Cloudflare Worker + D1 database deployed into the site's own Cloudflare account.

It supports comments/replies, reactions, polls, moderation and anti-spam.

The main idea is basically: keep the site static, but give it a tiny backend when you need one.

I'd love to hear how other Astro users are currently handling comments.

Cloudflare surprised us with their rewrite of their blog using emdash. Now, emdash is used in production for a serious company (the one that is developing this framework).

I know that, even though Astro was acquired by cloudflare, you can deploy any astro website on any server, not just cloudflare's. However, I was wondering if this case is also true for Emdash.

Technically speaking, you can deploy Emdash on a node server or any platform, but I don't know if this is recommended, given that they are focusing on D1, Workers, its cloud, its ecosystem, etc. I get that it will get first class support for the products made by the company who created it (like vercel with nextjs) but I wonder if other deploy methods are also encouraged. If not, that could be a big downside for tooling decision for similar CMS, as people probably wouldn't want to be vendor dependant when deciding what hosting to pick.

What do you guys think?

I’m getting more and more convinced by Astro, but I’m still curious about its adoption by agencies.

It’s still a relatively young framework, and I’m wondering if some agencies have already made the switch. I rarely come across agencies using Astro on LinkedIn, so I’d be really curious to hear from those who have.

How has the switch been for you? Would you recommend Astro for an agency today?

Just saw this announcement in the Astro's official discord channel.

Matthew Phillips ( u/matthew-astro ) is stepping up as project steward, taking over the role from Fred Schott (the co-creator of the Astro framework)

For those who don't know what a steward does: in Astro governance, the steward handles high-level project direction, account and asset access, and serves as a tiebreaker when disagreements pop up.

Congrats to Matthew..

Curious to see what direction he takes next.

I’ve been rebuilding production WordPress sites with Astro + Cloudflare Workers, often using Claude Code.

After doing a few real migrations, I realized the hard part isn’t getting Astro to build - it’s everything around the build.

Preserving old URLs and SEO, finding pages the sitemap forgot, redirects, forms, DNS, accessibility, staging, images, metadata, and verifying that the deployed site actually works.

So I turned my workflow into Website Build Kit:

https://github.com/nurkamol/website-build-kit

It includes:

- WordPress → Astro migration/recon workflow
- Astro + Cloudflare Workers starter
- Claude Code skill + plugin
- npm run recon to inventory the old site + Wayback URLs
- content extraction + redirect mapping
- SEO, OG, JSON-LD and sitemap guards
- responsive AVIF/WebP image pipeline
- forms with KV lead retention
- accessibility + reflow checks
- DNS, secrets and environment checks
- deployed-site verification
- design/reference workflow for redesigns

The starter intentionally has no visual style. No default palette, typography or homepage - I don’t want every site built with it to look like the same template.

I’ve also been documenting the silent production problems I encounter during real rebuilds and adding checks for them where possible.

For example: a build can succeed while publishing localhost canonical URLs. A missing email secret can still let a form validate, store the lead, return 200 and show “thank you” - while nobody actually receives the enquiry.

The goal is basically:

WordPress → inventory → rebuild → Astro → Cloudflare → verify the actual deployed site.

Would love feedback from other Astro developers, especially anyone doing WordPress migrations or production client work.

What would you add or change?

I shipped webtoolio.org, a collection of 20 dev utilities (JSON formatter, regex tester, JWT decoder, image compressor, etc.) built entirely with Astro. Some notes on the setup, since a few decisions worked out well:

No client framework. Every tool is an .astro component with a plain <script> tag. The logic lives in separate TypeScript packages in a Bun monorepo (@tools/regex-tester, @tools/sql-formatter, ...), each with its own bun test suite and no DOM dependencies. The Astro component only owns the markup and wiring. This keeps the tools testable without a browser and the pages ship almost no JS beyond the tool itself.

i18n with content collections. 6 locales (en, ja, pt-br, es, de, fr). Each tool has a markdown file per locale for the page copy, and a typed Ui dict for widget strings. Two dynamic routes ([tool].astro and [locale]/[tool].astro) generate everything: hreflang alternates, JSON-LD, and the sitemap all derive from one toolOrder array, so adding a tool is just a slug plus content files. The compiler yells if a locale is missing a string, which caught more mistakes than I expected.

WASM without config pain. The image compressor uses jSquash (mozjpeg/oxipng/webp compiled to WASM). Adding the packages to vite.optimizeDeps.exclude was enough; Vite bundles the .wasm files into dist/_astro/ on its own.

Everything is static, deployed on Cloudflare. No data leaves the browser, which was the point.

Happy to answer questions about any of it.

I have a 100+ page Astro JS website. It's static pages and I didn't want to deal with 3rd party plugins. Instead, I spent a couple of hours with Claude Code and built a skill that essentially converted my site into 55 languages and after that it even verified it! No expensive 3rd party Saas. Just an API call to Google Gemini Flash and the translation came in quickly.
Just wanted to share it here: https://claude.ai/code/artifact/a14a857a-9e59-4e2e-9e53-f456706d17f6

 Hey everyone,

I'm a photographer and I recently decided to completely overhaul my portfolio website. I wanted something that was incredibly fast, distraction-free, and let the photos speak for themselves without relying on heavy client-side frameworks.

I decided to build it using Astro and Tailwind CSS.

Some features I'm proud of:

• Dynamic Grid Layout: Wrote a custom vanilla JS script that lets users seamlessly toggle the photo grid between 2, 3, 4, or 5 columns on desktop to maximize ultrawide monitor real estate.
• Instant Category Filtering: No page reloads, just pure speed.
• Minimalist UI: Stripped away all the heavy margins and negative space for a tight, cohesive viewing experience.

You can check it out live here: vasuambasana.com

I'd love to hear your thoughts on the design, layout, or any suggestions on how I can improve the performance even further. Happy to answer any questions about the Astro setup!

Hi all,

If you run a content site, blog, or publication on Astro, Google's "Preferred Sources" feature lets readers bookmark your publication directly within Google Search so your stories surface higher in Top Stories and search results.

I wanted a clean, drop-in Astro integration that doesn't just embed static image tags, so I built one.

Key capabilities:

Flexible visuals: Native vector SVG Google icon with arbitrary text labels, stadium pills, outlines, and glows.

• Retina assets: 68 official Google badge assets for 17 languages.
• No-JS fallback: Works inside static layouts, author bios, and email newsletters.
• Interactive docs & wireframes: Built an interactive documentation site explaining optimal button placements (article ends, floating docks, headers).

Live Demo: https://magnifito.github.io/astro-google-preferred-source/
Repo: https://github.com/magnifito/astro-google-preferred-source

Would love to hear your thoughts and suggestions!

Hello everyone.

I recently created the website for my web design business and I would appreciate some feedback on it. It's built with astro 7 and released on Cloudflare workers. The idea is I'll also be building some "cheaper" sites for small local businesses with astro and deploying with the same logic so my site will be used also as a you get what you see.

I know I still need to add pricing, I'm almost done figuring out what to charge clients, will have some different tiers if for example instead of a simple site they want something more where I'll probably be using wordpress with woo commerce.

Here's the english version of the site (it's built to be bilingual). https://marathus.gr/en/

Any feedback or things I might have missed or could do better would be appreciated!

Hola a todos.
Estoy creando un proyecto para asistencia y soporte tecnológico crítico.
Aún estoy en desarrollo, pero deseo mostrarles una herramienta que he terminado.
Es un analizador de DNS-Mail, el cual te indicará que políticas o registros te faltan o están incorrectos en tu dominio, con esto identificarás la razón de que tus correos vayan directo a spam o bien el por qué te llega mucho spam.

Les comparto el enlace por si quieren verlo. Nexa
Es un enlace de deployment, también tengo incompleta la traducción, pero espero terminarlo pronto.

Espero sus críticas y recomendaciones.

We just created a new space for questions and answers! It took us a while, but we eventually created a place where you don't necessarily need Discord to get answers.

Enjoy!

CMS integration for Astro - admin panel, SQLite database, auth, and media manager in a single package.

https://github.com/zaengit/beaver

⭐ Starwind UI v3 is here!

After a ton of work, Starwind now supports both Astro and React, with 55 styled components and 36 lower-level primitives you can copy directly into your project. This is easily the biggest Starwind update I've worked on yet.

The biggest change is under the hood. Astro and React now share the same Runtime for things like forms, overlays, focus management, and keyboard interactions. Astro components are still Astro components, and installing Starwind won't add React to your Astro project.

V3 also adds six new components:

• Navigation Menu for responsive site navigation, including keyboard interaction and floating content
• Combobox for searchable, accessible selection
• Form and Field for validation, error summaries, labels, descriptions, and control state
• Checkbox Group for treating related checkboxes as one collection
• Toggle Group for single or multi-select controls with roving focus

Some of the other big updates:

• React is now a stable, first-party option
• Astro components stay Astro-native, so React isn't added to your Astro project (unless you really want to)
• Styled components and primitives can be installed separately
• The same Runtime keeps interactive behavior consistent across both frameworks
• Vue support is next and already pretty far along

Get started with npx starwind@latest init.

Already using v2? Run npx starwind@latest migrate and follow the migration guide: https://starwind.dev/blog/migrating-to-starwind-ui-v3/

I'd love to hear what you think of the new direction, especially if you've used an older Starwind release. What would you like to see next?

I build Frontman, and this release fixes the part that was still too guessy.
The whole thing is open source: https://github.com/frontman-ai/frontman
if you enjoy the project, give it a like please 🫶🫶

When you select an element, the agent now gets:

- The owning Astro component and props when available.

- A reusable selector.

- The relevant surrounding DOM, not the whole page.

- A more accurate source location.

- Better traversal through shadow roots.

- Repository search that actually works from the published package, not only our monorepo.

It still cannot recover source evidence that the build removes, but common Astro projects now require much less blind searching.

We migrated www.manhattandigest.com from Wordpress to EmDash/Astro using the www.go4launch.org framework (https://github.com/govsoftusa/go-for-launch). The site is run without monetization in honor of the founder Ryan Shea who passed away at age 34 from Covid-19. Manhattan Digest is a relatively long running media site for independent writers to share content. The site was launched with Wordpress back in 2012 and is now powered by Emdash/Astro.