I'm using wordpress where i've got bunch of forms live on the site and CRMs are connected to the funnel. What's the workaround?

I wrote up a small project where I moved my personal site away from WordPress because I wanted a better AI-assisted editing workflow.

The basic setup:

- posts in Markdown

- Astro builds the static site

- Cloudflare Pages hosts it

- Content is saved in git, and I can use AI coding agents to handle post tags, image alt tags, descriptions, metadata, etc.

- a local Python/Docker app handles publishing with an Azure DevOps-like pipeline

- the admin side is not exposed publicly

It took some work to solve comments and contact form on the site, but I used CommentBox and Web3Forms to do that so it could still be a static site.

CloudFlare pages makes hosting free with better performance and fewer security concerns.

If you've done something similarr, I'd be interested to hear more about your editor / publishing workflow.

I’ve just spent the last 2 weeks migrating my travel tour website from WordPress + Elementor to Astro.

The site has:

• Nearly 1000 blog posts
• 200+ custom Elementor components/widgets
• Around 5 years of accumulated structure/content

So far, I’ve finished:

• Most of the frontend migration
• Part of the backend/system architecture

Honestly, the performance difference already feels huge.

Now I’m trying to avoid making mistakes in the next phase, especially because this is a real business website focused heavily on SEO and content.

Besides the UI/frontend part (which is mostly done), what should I pay extra attention to during and after migration?

Things already on my radar:

• SEO preservation & redirects
• Core Web Vitals
• Security
• Structured data/schema
• Image optimization/CDN
• Caching strategy

But I’d really love to hear practical lessons from people who already migrated large WordPress sites to Astro (or other static/hybrid frameworks).

Especially interested in:

• Unexpected SEO issues
• Traffic drops/recovery timelines
• Handling old media URLs
• Search/indexing problems
• CMS/editor workflow after leaving WordPress
• Things you wish you knew earlier

Would appreciate any advice or war stories 🙏

https://preview.redd.it/4lvbensth41h1.png?width=3024&format=png&auto=webp&s=ad7ea6082765bdf9a39ce57b23ea34e9083fee12

Hey guys,

I just finished setting up i18n for my site. Astro's routing makes the folder structure super easy, but translating the actual content in src/content/blog is a different story.

At first, I tried to just let an AI coding agent (using Gemini Flash 3 for speed, in Antigravity) do the translation for me directly on the .md files in my editor. It was a disaster.

Not only was it painfully slow (I could only get through about 3-5 articles per run before it would stall out), but worse, the LLM started getting "lazy". Instead of giving me a 1:1 detailed translation, it started outputting summarized, truncated versions of my articles to save effort. On top of that, it kept hallucinating yaml frontmatter and breaking my custom Astro components.

I realized agentic translation just wasn't scalable for a whole CMS. And since that website is actually the marketing website of my app that's dedicated to batch CSV translations (check AI Glot if interested), I figured I should just use my own tool. I just needed to bridge the gap between Markdown and CSV, because I initially built it 2 years ago for Weglot translations which handles everything via CSV.

So, I put together two simple Node scripts: one to extract the text to a CSV, and one to import it back.

Here is what the workflow looks like and some concrete gotchas if you want to set it up:

1. the extraction script I wrote a Node script that crawls my src/content/blog/en folder. It parses the frontmatter (catching title, metaDescription, and even custom arrays like faqs) and splits the body text by \n\n+ to isolate paragraphs.

It spits all of this out into a simple CSV with columns: path, English string, and my target locales (fr, es, etc).

Two important details for this script:

• It explicitly skips over lines starting with ``` so code blocks never get sent to the translator.
• It has pre-fill logic: if a localized .md file already exists, it maps the existing translations back into the CSV. This means when I add a new paragraph to an old post, I don't have to re-translate the entire file.

1. the translation Once I had a clean CSV with just the english strings, I could translate it in bulk. You could just write a quick python script to loop through the rows and hit the OpenAI API. I just threw it into AI Glot to handle the batches and apply glossaries (so it doesn't try to translate technical words like "Astro" or "Frontmatter" into French or Spanish).
2. putting it back together (the tricky part) Then I have an assembly Node script that takes the translated CSV and rebuilds the markdown files. This was trickier than it sounds.

the workflow:

[ /src/content/blog/en/*.md ] 
            │
            ▼ (extract-translations.mjs)
[ multilang-translation.csv ]  <-- Clean text only, no formatting/code blocks
            │
            ▼ (Batch AI Translation via AI Glot / Python script)
[ translated_fr.csv, translated_es.csv, etc ]
            │
            ▼ (assemble-blog-translations.mjs)
[ /src/content/blog/fr/*.md ]  <-- Reassembled with perfect frontmatter & formatting

If you build this yourself, here are the concrete gotchas my assembly script handles:

• String replacement bugs: You must sort your CSV translation chunks by length (descending) before doing the string replacement in the markdown file. Otherwise, if the script replaces "Astro" before it replaces the longer phrase "Astro i18n API", it will corrupt the string.
• Image path depths: Astro localized content usually sits one directory deeper (e.g., src/content/blog/fr/live/ instead of src/content/blog/live/). The script runs a quick .replace('../../../assets/', '../../../../assets/') to automatically fix relative image references.
• Internal link localization: It runs a regex (/\]\(\/([\w\-\/]+)\)/g) to automatically prepend the locale to any internal markdown links (so [Read more](/blog/slug) becomes [Read more](/fr/blog/slug)).
• Frontmatter injection: It automatically updates the yaml frontmatter to flip isDraft: false and injects locale: "fr".

The best part about doing it this way is that you never break your formatting, and you don't end up with lazy, summarized translations.

Thought I'd share this since markdown translation seems to be a common pain point when scaling a markdown based Astro CMS. If anyone wants the actual extract-translations.mjs and assemble-blog-translations.mjs code, let me know and I'll drop the gists in the comments!

SEO is still used widely in website development yet AEO (answer engine optimization) is quickly becoming more important and more people are using ChatGPT, Gemini, Claude and other LLMs to search for information.

I have made a free resource for those interested in creating dynamic components or pages that are specific to AI search engines.

Hello, I'm Searching for testimony about creating full website for a SaaS B2B enterprise dedicated for industrial purposes.

I'm completely novice in code, but I want to learn, and use a mix of sanity for CMS / our own hosting / astro / Claude design for components generation and a based template to use Astro.

What do you think about?

I released JustOpinion, a lightweight hosted comment system for static sites, including Astro sites.

The integration is a generated CSS + JS snippet that can be added where you want comments to appear. Each page gets its own thread.

Would appreciate feedback from Astro users:
https://www.justopinion.online

I've been working on a Headless CMS called Nodify for a while now, and I finally added a feature I've wanted for a long time: automatic static site generation (SSG). 🚀

What is Nodify?

It's an open-source Headless CMS that you can self-host. It handles content versioning, multi-language support, and customizable workflows. It’s completely free and gives you an API to deliver content anywhere.

How the SSG mode works

I wanted to bridge the gap between managing content and deploying. Now, when you create content in Nodify, you can just mark it as "SSG enabled". You set a destination folder and a webhook URL, and that’s it.

When you hit publish, Nodify sends a webhook to your receiver (GitHub Action, Netlify, Vercel, etc.). The receiver fetches the content from the API and builds the site. I personally use it with GitHub Pages: the Action pulls the data and commits the files to a branch automatically.

Why I built this

I wanted one single place to manage multiple static sites with the same templating and versioning logic. The goal was "publish and forget": non-technical users get a proper UI, but developers keep their Git history and workflow. No vendor lock-in, your data stays with you.

Links & Feedback

• Demo: https://nodify.azirar.ovh
• GitHub: https://github.com/AZIRARM/nodify

The docs have the technical details on the webhook structure and setup.

If you want to know more about the payload or the receiver configuration, just ask me here or check the repo. I'll be around all day to answer your messages!

Would love to hear your thoughts or any criticism. 👋

Tags: #ShowHN #HeadlessCMS #OpenSource #Jamstack #SSG #Selfhosted #CMS

My site is mostly static with few JavaScript and little reactivity but I really want to have the data sent from the server to be typed which sadly Eta nor Ejs support. I'm also not really a favor of some frameworks that use custom syntax for HTML and such. Astro looks mostly just vanilla HTML to me which I like. Do you guys think Astro would be the best fit for this type of project?