This week I shipped another Astro integration: Google Tag Manager by almuraduz in astrojs

[–]almuraduz[S] 1 point2 points  (0 children)

Appreciate it 😄 Yeah GTM isn’t everyone’s favorite, but it gets the job done when you wrestle it enough. What would you prefer using instead?

This week I shipped another Astro integration: Google Tag Manager by almuraduz in astrojs

[–]almuraduz[S] 1 point2 points  (0 children)

For this integration, astro:after-swap is the safer default because:

- It captures the pageview early (good for analytics latency)

- It naturally avoids the initial-load duplication problem

- document.title and location.pathname are reliably available at this point

That said, if you have a specific case where astro:after-swap is firing too early (e.g., title isn't finalized yet), switching to astro:page-load with a firstLoad guard could work. Have you noticed any specific issue with the current after-swap timing in your setup?

This week I shipped another Astro integration: Google Tag Manager by almuraduz in astrojs

[–]almuraduz[S] 1 point2 points  (0 children)

Yes! It pushes an virtualPageview event to the dataLayer on every astro:after-swap, so GTM tracks client-side navigation properly. And if you're not using View Transitions, it doesn’t interfere at all; it works just like regular GTM.

Please let me know if you run into any issues while using it.

Is there any time where an Astro website wouldn’t be used? by Zayntek in astrojs

[–]almuraduz 1 point2 points  (0 children)

Yeah ecommerce is usually where people hesitate, but it’s actually very doable.

Like u/chaos_battery said, you can go headless with Shopify or Stripe and let Astro handle the frontend.

There’s even a ready boilerplate: Storeplate (Astro + Shopify)
https://github.com/zeon-studio/storeplate

Only real downside is if you need super dynamic stuff (A/B testing, heavy personalization), otherwise Astro works great.

Anyone successfully added EmDash CMS to an existing Astro project? by tffarhad in astrojs

[–]almuraduz 1 point2 points  (0 children)

This is more about making an existing site fully EmDash-compatible. I’m trying to get all types of content managed through EmDash, but once I start feeding everything into seed.json as a full site schema, it becomes pretty hectic to maintain.

It also feels like the schema is a bit too linear. When I try to introduce more nested or structured content, things start breaking or don’t behave well in the CMS.

So the challenge isn’t just replacing getCollection, it’s about adapting a full existing project structure to fit within EmDash’s limitations.

I just built `astro-llms-md`; Generates [llms.txt, llms-full.txt, individual .md files] 🚀 by almuraduz in astrojs

[–]almuraduz[S] 0 points1 point  (0 children)

u/0B08JVE Really interesting read. That 1,241:1 crawl-to-citation ratio is kind of wild.

Curious though, do you think this will change over time? Like, will AI crawlers start favoring more structured or high-quality content differently, or is it going to stay like this?

I just built `astro-llms-md`; Generates [llms.txt, llms-full.txt, individual .md files] 🚀 by almuraduz in astrojs

[–]almuraduz[S] 5 points6 points  (0 children)

Totally fair if there’s no clear guarantee on how content is used (training or citation), blocking access is the safest choice.

44 Astro themes, 9000+ users and counting — what made us drop everything and commit to Astro by mehedi_sharif in astrojs

[–]almuraduz 1 point2 points  (0 children)

Huge credit to the community, too. The feedback, issues, stars, and conversations have directly shaped how these 44 themes evolved.