Dynamic Sitemap

[nayanrabiul]

need for a dynamic method to generate a sitemap for server-side rendering (SSR) mode. This is particularly important in scenarios like an E-commerce website where products are constantly changing. Without such a dynamic approach, it becomes challenging to keep track of what products are available in the store.

[bholmesdev]

Thanks for sharing this @nayanrabiul! I was about to open this discussion myself per discussion on this issue.

It sounds like Next.js has a solution to this, where you specify the routes you want to prerender for use in the sitemap. As a developer, you could enumerate your pages and map to URLs:

// sitemap.ts
const Pages = pages?.map((page) => ({
    url: `${baseUrl}/${page.params.pageSlug}`,
  }));

Trouble is, all sitemap configuration lives in your astro.config.mjs today. This wouldn't have access to your runtime pages. Our RSS integration gets around this by requiring you to add an rss.xml.ts file to your src/pages for generation. Perhaps we could move sitemap to a similar model?

[nayanrabiul]

yes, i didnt foundt it online, but i try it dont know why and it works. Thnaks for answering.

[Fryuni]

Although it is not for a fully dynamic sitemap, where it can change without a rebuild, you can have a look at my Sitemap Extensions built on top of the official Sitemap integration.
It doesn't solve what you are describing exactly how you want it, but depending on your use case, it might be enough.

[Fryuni]

Exactly!

[bholmesdev]

Sweet! In that case, this is pretty compelling as a core feature of the sitemap integration. Do you have any interest in leading a small stage 2 on this @Fryuni?

[Fryuni]

Sure, I can make an RFC for that!

It wouldn't be that small 😅
Well, it would be small but not simple, or at least not the implementation.

The extension is based on an AIK plugin I made (still undocumented) that injects a separate integration to modify the result from the compiler in order to know on which route the component is used and call that function for SSR pages during build-time.

Moving it to the official integration would allow it to be much simpler but still way more complicated than the current integration.

[bholmesdev]

@Fryuni Ah, good to know the lift involved. I'm also not sure the fully featureset of your integration would be required to fulfill this discussion. Would making this feature SSR-only lessen the lift?

[Fryuni]

Making the sitemap itself SSR would be a redesign of the lib since it currently all runs in build time to generate a static sitemap. But it might actually be simpler though, maybe that's a great idea.

More features, more powerful, might be interesting.