#Contentful hook and revalidatePath for sitemap

1 messages · Page 1 of 1 (latest)

versed ravine
#

It is known that we can use revalidate on sitemap.ts to expire the sitemap after an amount of time and regenerate it without rebuilding the application. Despite that, I have a technical requirement of using the current hooks configured on Contentful that trigger the revalidate route, so that on every Publish the revalidate route also revalidates the sitemap and regenerates it. Currently the revalidate has revalidatePath('/', 'layout'), and I added revalidatePath('/sitemap.xml') below it to no avail. How can I use revalidatePath to revalidate the sitemap? What are the options using the Contenful hook besides exporting revalidate on the sitemap.ts?

limber ospreyBOT
#

Hi @versed ravine. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

To revalidate your sitemap in response to a Contentful webhook (on publish), you want your API route (e.g., /api/revalidate) to call revalidatePath('/sitemap.xml') so that the sitemap is regenerated on the next request. However, there are some important caveats and current limitations in Next.js:

1. Using revalidatePath for /sitemap.xml

  • According to the Next.js documentation, you can call revalidatePath('/sitemap.xml') in a Route Handler or Server Action to invalidate the cache for that path. This should, in theory, cause the sitemap to be regenerated on the next request.
  • However, there are reports (see GitHub Issue #61616) that the sitemap route is not always cached as expected, and that exporting revalidate from sitemap.ts does not always control the cache headers or behavior as it does for regular pages. This means that even after calling revalidatePath('/sitemap.xml'), the sitemap may not be cached or may not be regenerated as you expect.

2. Options with Contentful Webhook

  • The standard approach is to have your Contentful webhook trigger a POST to your /api/revalidate endpoint, and in that handler, call revalidatePath for the relevant paths (e.g., your homepage, blog, and /sitemap.xml) Vercel Blog Example.

  • Example handler:

    import { revalidatePath } from 'next/cache';

export async function GET(request) {
  revalidatePath('/');
  revalidatePath('/sitemap.xml');
  return Response.json({ revalidated: true });
}

  • This is the correct pattern, but as noted above, the effectiveness for /sitemap.xml depends on Next.js's current caching behavior for sitemaps.

#

3. Exporting revalidate from sitemap.ts

  • You can export export const revalidate = 3600; from your sitemap.ts to set a time-based revalidation, but this is not on-demand and does not respond to webhook events. It simply sets a cache lifetime Sitemap Docs.

4. Current Limitations

  • As of now, there is no guarantee that revalidatePath('/sitemap.xml') will work as expected due to the way Next.js handles caching for special files like sitemaps (GitHub Issue #61616). The cache headers may not be set for long-term caching, and the file may be regenerated on every request regardless.
  • There is no documented alternative in the knowledge sources for forcing a regeneration of the sitemap via a webhook beyond what you are already doing.

Summary:
You are using the correct approach by calling revalidatePath('/sitemap.xml') in your webhook handler, but due to current Next.js limitations, this may not always work as expected. Exporting revalidate from sitemap.ts only enables time-based revalidation, not on-demand. There is no alternative method documented in the knowledge sources for on-demand sitemap regeneration beyond this pattern. You may want to follow or comment on the related GitHub issue for updates on this limitation.

#

@versed ravine Kapa.ai is still learning and improving, please let me know how I did by reacting below.

versed ravine
#

@limber osprey Assuming the best option here would be exporting revalidate in the sitemap.ts, can an option be:

  • publishing triggers a call to /sitemap.xml, which would return the old sitemap right?
  • if revalidate expired, accessing the sitemap would then return the new sitemap?
  • would this solution harm some kind of best practices? should I just rely on the export of revalidate without hooks and etc.?
limber ospreyBOT
#

Let me check the knowledge base for you again. Give me one moment! :books:

#

Your understanding of how exporting revalidate in sitemap.ts works is correct:

  • If you export revalidate in sitemap.ts, the sitemap will be cached and only regenerated after the specified interval (e.g., every hour if you set export const revalidate = 3600;).
  • If a webhook triggers a call to /sitemap.xml, and the cache has not expired, the old sitemap will be served.
  • If the cache has expired, the next request to /sitemap.xml will serve the old sitemap immediately, but Next.js will regenerate the sitemap in the background. The following request will then receive the updated sitemap. This is the standard "stale-while-revalidate" behavior in Next.js time-based revalidation see docs.

Does this approach violate best practices?

  • This approach is acceptable and aligns with Next.js best practices for time-based revalidation.
  • Triggering a fetch to /sitemap.xml via a webhook is not harmful, but it does not guarantee immediate regeneration. The first request after expiration will always return the stale sitemap while regeneration happens in the background see docs.
  • If you need the sitemap to be updated immediately after publishing (i.e., no stale data served), time-based revalidation alone is not sufficient. On-demand revalidation (e.g., with revalidatePath) would be required, but as discussed earlier, this may not work reliably for sitemaps due to current Next.js limitations see issue.

Should you rely only on revalidate?

#
  • If your use case tolerates a short delay (the time it takes for the next request after expiration to trigger regeneration), relying on revalidate is a simple and robust solution.
  • If you require immediate updates, the current Next.js implementation does not guarantee this for sitemaps, so you may need to accept the time-based approach until the framework provides better support for on-demand sitemap regeneration.

In summary:
Relying on export const revalidate = ... in sitemap.ts is a best-practice, supported solution. Triggering a fetch to /sitemap.xml after publishing is not harmful, but it will not force immediate regeneration—only the next request after expiration will do so, and the first response will still be stale. This is the intended behavior for time-based revalidation in Next.js see docs.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: