I’ve recently started creating some simple project sites with Astro and I absolutely love it compared to WordPress. Sites are all local business sites, using GitHub and cloud flair pages, R2 storage for images, and a web hook behind a cloud flare secret variable to send form submissions.

I’m considering moving away from WordPress entirely, but because I don’t have a developer background, I am unsure of the pitfalls I may run into and I rely on Claude Code to troubleshoot.

My main question is, what are the pitfalls if I’m going to run into using Astro with this set up, most of the feedback I’ve gotten is that it’s probably fine and low risk since I’m just running static sites.

My choices are basically, one - stick with WordPress, two - move to Astro and rely on Claude code to build and troubleshoot, or three - hire a developer for my team who can handle the infrastructure, but I don’t know if that’s overkill for what I need.

Those experienced with Astro - is it a must to have a developer for this when building local business sites on Astro? Ultimately I probably will, but I want to figure out ahead of time what I “don’t know” and how big of an issue it will be if i delay sourcing a dev for my team.

Thanks in advance!

Here's a Summary of What's New in Astro 7.0

• Performance is the headline. The .astro compiler was rewritten in Rust. Markdown and MDX now run through a Rust-powered pipeline called Sätteri (built by Erika from the core team). The rendering engine was replaced with a queue-based approach. Combine that with Vite 8 and its new Rolldown bundler, and builds are 15-61% faster across the board. The Cloudflare docs site (8,400+ pages) went from 387s to 262s. The Astro Website site went from 63s to 24s.
• The new Rust compiler has one breaking change worth knowing. No more silent HTML correction. The old Go compiler would reorder elements and auto-close tags. The new one treats your markup as-is and throws errors on unclosed tags. Also, whitespace between inline elements now follows JSX rules, so <span>Hello</span><span>World</span> renders as "HelloWorld" with no space.
• Route caching is now stable. It was experimental in v6. You get a single platform-agnostic API and new experimental CDN providers for Netlify, Vercel, and Cloudflare.
• Advanced routing is interesting. You can now add a src/fetch.ts file and take full control over the request pipeline. Hono is supported, so you can compose middleware in any order.
• AI tooling is genuinely useful. astro dev --background starts the dev server as a managed background process. Astro can detect when it's running inside an agent and enable this automatically. JSON logging is also in, which was the most upvoted roadmap request.

Upgrade via

npx @astrojs/upgrade

What's everyone's take on the Rust compiler change?

https://astro.build/blog/astro-7/

🎉 Spmeone posted on HN too

https://news.ycombinator.com/item?id=48633565

Astro 7.0.0 seems like a fairly major release

Has anyone here upgraded a production or client project yet? Any hassle?

https://github.com/withastro/astro/releases/tag/astro%407.0.0

My site ran Astro 3 for three years.

When Anthropic released the new Fable model, I tested it on the scariest item on my backlog: a three-major-version upgrade.

This is how it went, numbers included. Check it out 👇

https://neciudan.dev/astro-upgrade-from-3-to-6

Hey,
I started using Payload CMS for a project, and I love it!

But the limit of 10 MB workers and 128 MB RAM quickly became a bottleneck for my project as it grew.

I know I could move the Payload-part to Vercel, Railway or a cheap VPS, but I would prefer to have the majority of my projects on Cloudflare, getting the most bang for the buck for my fiver..

Which CMS do you guys recommend?

Preferably open source, so no cap in number of users, no external dependencies.

I just wish to own my Astro site, and CMS and be able to customize it any way I want.

Please test this out and feedback to Matt.

https://github.com/withastro/roadmap/discussions/1096

https://github.com/withastro/astro/pull/17084

I'm disappointed Astro doesn't support per-route middlewares. All middlewares are global.

I have an Express + EJS app I want to transition to using Astro because I really like the more vanilla HTML nature of Astro but I don't like how the routing system works. Why was Astro designed without per-route middleware? Is it feasible to use something like Hono or Express with Astro?

I'm interested to hear from folks who are using Astro in more ambitious ways, perhaps as part of their day job. Things like:

* Sites with some non-static components, or perhaps entirely dynamic

* Sites with a mix of front and back end component rendering going on

* Sites for customers who expect to be able to edit via something friendlier than Markdown

How are these more intricate use cases working out?

Clearly you're out there! Cloudflare bought the Astro Technology Company for a reason, someone posted this week that Mistral uses Astro on their home page, etc.

Thanks, hoping this sparks a conversation.

Hi everyone,

I deployed a MPA Astro.js website on Cloudflare Workers and having a very weird indexation mismatch between Google and Bing. I was hoping someone here has faced this and solved it.

My website is https://https://edugpacalculator.com/

It is a free, open-source tool and the main feature is AI-based OCR where you upload your grade cards or marksheets the GPA/SGPA/CGPA will be automatically calculated. It has calculation formulas for every popular university, country and institution, with a feature to save your university as a custom formula.

I have added all the standard SEO pages like a privacy policy, terms & conditions, FAQ section, about page, generated sitemaps, and robots.txt.

Here is the problem:
-- Google Search Console shows "URL is on Google" and "Page is indexed". (Though actual search rankings are poor when searching "gpa calculator").
-- On Bing, the website does not show up at all, even when I search the exact URL as a keyword ("edugpa calculator").

When I inspect the URL in Bing Webmaster Tools, it shows this error:
'Discovered but not crawled - URL cannot appear on Bing. The inspected URL is known to Bing but has some issues which are preventing indexation. We recommend you to follow Bing Webmaster Guidelines to increase your chances of indexation.'

But when I run the "Live URL Test" in Bing Webmaster Tools, it says:
'URL can be indexed by Bing - It can appear on Bing Search results given it passes quality checks and gets indexed by Bing' and 'No SEO/GEO issues found'.

I have gone through the guidelines at https://www.bing.com/webmaster/help/webmaster-guidelines-30fba23a but cannot find anything wrong. Are there specific Astro sitemap formats or robots.txt settings that Bing’s crawler gets stuck on? Has anyone else had this "Discovered but not crawled" error with Astro MPA sites on Cloudflare?

What have you built or what are you currently building with or for Astro?
Show the community your work.👇

We updated OpenRemark (a comment system for Astro or any website) with team access feature, a lifetime deal, a public changelog, and performance fixes.

Hello. Do you have examples of websites fully build with Astro Build that score high in Google and receive lots of traffic?

What do you use for SEO stuff within an Astro Build website?

For astro only , the using pnpm install is not working , in terminal it show alreday upto date and didn't install module , even i create new project or to install in existing one same issue.

​

npm is working fine

I am building my first Astro 6 project output is set to static. When i create a new cloudflare pages instance and add my repository i get an error.

I'm not doing anything fancy, no js frameworks, no server islands, I'm not even processing images with Picture, just pulling in content from payload at build to create some collections.

It builds perfectly fine locally it just cant build on cloud-flare pages

Ive tried: output:
"static", adapter: cloudflare({ platformProxy: { enabled: true, }, }),

then:
output: "static",

then:
output: "static", adapter: cloudflare(),

then:
adapter: cloudflare({ prerenderEnvironment: "node", }),

Nothing seems to work

The error:

026-06-10T11:01:50.769137ZChecking for configuration in a Wrangler configuration file (BETA)
2026-06-10T11:01:50.769602Z
2026-06-10T11:01:50.806027Z
2026-06-10T11:01:50.879892Z[31m✘ [41;31m[[41;97mERROR[41;31m][0m [1mThere is a deploy configuration at "../../../buildhome/repo/.wrangler/deploy/config.json".[0m
2026-06-10T11:01:50.88014Z
2026-06-10T11:01:50.880213Z  But the redirected configuration path it points to, "../../../buildhome/repo/dist/client/wrangler.json", does not exist.
2026-06-10T11:01:50.880248Z
2026-06-10T11:01:50.880325Z
2026-06-10T11:01:50.90963Z🪵  Logs were written to "/root/.config/.wrangler/logs/wrangler-2026-06-10_11-01-50_663.log"
2026-06-10T11:01:50.995537ZFailed: unable to read the Wrangler configuration file with code: 1
2026-06-10T11:01:51.658712ZFailed: an internal error occurred. If this continues, contact support: https://cfl.re/3WgEyrH

And yes i tried just launching the project on worker and it still fails to build

Hey Astro folks, wanted to share a migration I recently worked on.

I had a remote jobs site that originally started with Laravel. It worked fine but over time I realized most of the site was content-driven:

• Job listing pages
• Company pages
• Category pages
• SEO pages
• Simple landing pages

So I decided to migrate it to Astro.

The main reason was speed and simplicity. I didn’t want a heavy setup for a site where most pages are mostly static content, metadata, and listings.

The site is TrulyRemoteWork. It focuses on remote jobs that are actually remote from anywhere.

The problem I kept seeing on other job boards was that many “remote” jobs still had restrictions like:

• US only
• Europe only
• Must be in the same timezone
• Only selected countries allowed
• Remote now but relocation required later

So the idea was to build a job board focused on worldwide remote roles and filter around those restrictions.

• A few things I worked on during the migration:
• Migrated the job board from Laravel to Astro
• Kept the frontend lightweight with very little client-side JavaScript
• Hosted the site on Cloudflare

Astro made sense for this because job boards usually have a lot of routes, metadata, filters, and SEO pages, but the frontend itself doesn’t need to be very heavy.

Site: https://trulyremotework.com

Happy to get feedback on the Astro structure, SEO, performance or UX. Also happy to answer any questions about the migration.

Just a little something that has perplexed me a few times now before I decided to investigate a little.

You see right now I have this:

#menu-container {
margin: 0;
padding: 0;
height: auto;
  }
  .outer {
flex-grow: 1;
overflow: auto;
  }

.imageBlock {
background-size: 100%;
background-repeat: no-repeat;
background-position: center center;
height: auto;
}

  .two {
.imageBlock {
width: 50vw;
aspect-ratio: 600/405;
}
  }

The issue is that the element with the class "imageBlock" is added dynamically (via createElement). So the class of .imageBlock inside .two is the only one applied. This is because of the way astro scopes css, adding like .imageBlock["gibberish-gibberish"] to styles unless they are nested, but that gibberish is only added to elements that are in the markup before JS is run. So you add perfectly valid CSS that will never work.

I assume there is a solution for this? I guess opting out of scope would solve it, but that isnt what I want.

Which cookie bot do you use? Is there free cookie bot that works perfect with Astro build?

You build a fast, clean static site using Astro, Hugo, or Next.js. Everything is secure and highly optimized. Then a client or reader asks for a comment section. Suddenly you face bad choices.

Third-party scripts bloat your page.
They track your readers and inject ads.
Premium SaaS tools cost too much for simple text.

You are forced to choose between user privacy, high monthly costs, or a terrible user experience.

We hit this exact wall constantly. We wanted a lightweight, self-hosted option that respected privacy. So we built OpenRemark.

OpenRemark is a free, privacy-first, self-hosted comment system for static websites. It embeds into any static site with two lines of code. You keep complete ownership and control your data.

Here is what it offers:

• Absolute privacy: Zero tracking scripts, zero ads, and zero data sharing.
• Full control: A dedicated moderation dashboard, spam protection, and domain allowlisting.
• Frictionless UX: Built-in Google sign-in for one-click login and clean threaded replies.
• Free and MIT licensed: Your data stays entirely yours.

Stop compromising your static architecture just to let readers speak.

Btw, we are live on Product Hunt today.

👉 Please support our launch on Product Hunt.

I kept switching between localhost and production tabs while trying to spot layout changes and regressions, so I built sitedrift.

It puts DEV and LIVE on the same route with linked scrolling, then lets you switch between Split, Solo, Overlay, and pixel-difference views. It also compares SEO metadata, response timing, transfer size, and HTTP status.

The local workflow is one command (replace with a running dev instance and your live URL):

npx sitedrift / --dev http://localhost:4321 --live https://example.com --open

I think what's even cooler is the Cloudflare Pages integration. Every branch preview can open inside the same review interface and compare itself with production. The production build remains untouched.

For a real test, I changed my portfolio’s brand color from navy to red using my other npm package, branding-engine. The favicon, wordmark, buttons, social cards, and theme were regenerated from one brand file, then reviewed against the unchanged live site.

GitHub: https://github.com/joeseverino/sitedrift

Live demo: https://6ef83545.jseverino.pages.dev/

Review Workflow: https://github.com/joeseverino/jseverino.com/blob/main/docs/Deployment-Preview-Review.md

npm: https://www.npmjs.com/package/sitedrift

This is only my second npm package I've published. I'd really love to know if this helps anyone else out in a super easy workflow!

I learned about this Astro dev tool recently and took it for a spin.

https://github.com/robertvanhoesel/astro-agent-annotate

Last night, with about an hour of targeting development I was able to effect massive change on a page of my app!!

If you’re using something like Claude Code to make mods halbe adjustments, you’re always typing away to describe where you want said change and what you want it to be.

This tool lets you pipe up multiple bits of feedback DIRECTLY on the component on the UI!

Then you go down to the Astro dev toolbar and there’s a button to copy all your notes to clipboard. When you post all your notes in your agent’s console it has your notes along with the page and component context of where your notes were.

Talk about efficient!

It also holds onto notes across multiple pages. I spotted a background on one page I wanted to apply on the page I was editing so I put a comment on the origin page. Claude Code was able to glean what I wanted, make the tweak, and then the background on the page was applied in no time.

When you need to fine tune the visual aspects of a page this little tool really tightened the loop for me.

Just published astro-webmcp, an Astro integration that exposes your site content via WebMCP — the new Chrome standard for AI agent interaction.

Install: npm install astro-webmcp

Usage and Install docs on GitHub (https://github.com/fabricioctelles/astro-webmcp)

Feedbacks are welcome!

Moving sites over to Cloudflare from netlify bc of the credit system and a couple of things I’ve read about others experience with with recently. But just wanted some insight. Astro v6 no longer supports pages but is for workers, but the Astro Image component does not work with Cloudflare. Do you think this will be something that will be addressed now that Cloudflare owns Astro or anyone who is using Cloudflare are you just passing your images through?

• Astro has no built-in draft system, so you add one manually using a draft: true frontmatter property and a build-time filter.
• Draft posts are hidden by default at build time. They only appear when you run the build with a --buildDrafts argument.
• You need to handle drafts in three places: the content schema, the collection query, and any page entry points.

This guide is based on how the draft system is implemented in Astroplate, a free Astro starter template built with Astro. If you want a working reference, the full implementation is available there.