app/sitemap.ts is not served at /sitemap.xml on NextJS 15RC #66232
Comments
|
It's an expected breaking change as the PR description mentioned, that we don't appending We mentioned in the blog post but didn't mention it as breaking change, I've updated the blog post that it's mentioned as below now
|
Thanks for the explanation. So there is no NextJS recommended way to serve the dynamic sitemap at |
|
As a solution you can add rewrites to next.config.js |
|
I had a PR (#66477) to improve the sitemap url generation, where we can always get a |
huozhi
added a commit
that referenced
this issue
Jun 10, 2024
#66477) ### What Optimizing the static generation for dynamic metadata routes If you're not using `generateSitemaps()` or `generateSitemaps()`, you don't need to change any file conventions. If you're using multi sitemap routes, make sure the returned `id` properties from `generateSitemaps()` don't need to contain `.xml`, since we'll always append one for you. Analyzing the exports of metadata routes and determine if we need to make them as dynamic routes. ### Why Previously, users are struggling with the multi routes of sitemap or images. For sitemap, the `.xml` extension in url doesn't get appended consistently to the multi sitemap route between dev and prod. For image routes, the generated image routes are always dynamic routes which cannot get static optimized. The reason is that we need to always generate a catch-all route (such as `/icon/[[...id]]` to handle both single route case (e.g. without `generateImageMetadata`, representing url `/icon`) or multi route (e.g. with `generateImageMetadata`, representing url `/icon/[id]`), only catch-all routes can do it. This approach fail the static optimization and make mapping url pretty difficult as parsing the file to check the module exports has to be done before it. #### Benifits For image routes urls, this approach could help on static generation such as single `/opengraph-image` route can be treated as static, and then it can get static optimized if possible. **Before**: `/opengraph-image/[[...id]]` cannot be optimized **After**: single route `/opengraph-image` and multi-route `/opengraph-image/[id]` are both possible to be statically optimized For sitemap, since we removed appending `.xml` for dynamic routes, it’s hard for users to have `/sitemap.xml` url with dynamic route convention `sitemap.js` . But users desire smooth migration and flexibility. **Before**: In v15 rc we removed the `.xml` appending that `sitemap.js` will generate url `/sitemap` makes users hard to migrate, as users need to re-submit the new sitemap url. **After**: Now we'll consistently generate the `.xml`. Single route will become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`. It's still better than v15 as the urls generation is consistent, no difference between dev and prod. Here's the url generation comparsion #### Before All the routes are dynamic which cannot be optimized, we only had a hacky optimization for prodution build multi-routes sitemap routes | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image/[[...id]] | /opengraph-image[[...id]]/ | /opengraph-image/[[...id]] | | sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev: `/sitemap/[[...id]]` prod: `/sitemap/[id]` | #### After Most of the single route will are to get statically optimized now, and the multi-routes sitemap are able to get SSG now | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - | | sitemap.js | /sitemap.xml | - | /sitemap/[id].xml | Next.js will have less overhead of mapping urls, we can easily multiply the urls generation simply based on file conventions. x-ref: feedback from #65507 Closes #66232
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
ForsakenHarmony
pushed a commit
that referenced
this issue
Aug 14, 2024
#66477) Optimizing the static generation for dynamic metadata routes If you're not using `generateSitemaps()` or `generateSitemaps()`, you don't need to change any file conventions. If you're using multi sitemap routes, make sure the returned `id` properties from `generateSitemaps()` don't need to contain `.xml`, since we'll always append one for you. Analyzing the exports of metadata routes and determine if we need to make them as dynamic routes. Previously, users are struggling with the multi routes of sitemap or images. For sitemap, the `.xml` extension in url doesn't get appended consistently to the multi sitemap route between dev and prod. For image routes, the generated image routes are always dynamic routes which cannot get static optimized. The reason is that we need to always generate a catch-all route (such as `/icon/[[...id]]` to handle both single route case (e.g. without `generateImageMetadata`, representing url `/icon`) or multi route (e.g. with `generateImageMetadata`, representing url `/icon/[id]`), only catch-all routes can do it. This approach fail the static optimization and make mapping url pretty difficult as parsing the file to check the module exports has to be done before it. For image routes urls, this approach could help on static generation such as single `/opengraph-image` route can be treated as static, and then it can get static optimized if possible. **Before**: `/opengraph-image/[[...id]]` cannot be optimized **After**: single route `/opengraph-image` and multi-route `/opengraph-image/[id]` are both possible to be statically optimized For sitemap, since we removed appending `.xml` for dynamic routes, it’s hard for users to have `/sitemap.xml` url with dynamic route convention `sitemap.js` . But users desire smooth migration and flexibility. **Before**: In v15 rc we removed the `.xml` appending that `sitemap.js` will generate url `/sitemap` makes users hard to migrate, as users need to re-submit the new sitemap url. **After**: Now we'll consistently generate the `.xml`. Single route will become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`. It's still better than v15 as the urls generation is consistent, no difference between dev and prod. Here's the url generation comparsion All the routes are dynamic which cannot be optimized, we only had a hacky optimization for prodution build multi-routes sitemap routes | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image/[[...id]] | /opengraph-image[[...id]]/ | /opengraph-image/[[...id]] | | sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev: `/sitemap/[[...id]]` prod: `/sitemap/[id]` | Most of the single route will are to get statically optimized now, and the multi-routes sitemap are able to get SSG now | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - | | sitemap.js | /sitemap.xml | - | /sitemap/[id].xml | Next.js will have less overhead of mapping urls, we can easily multiply the urls generation simply based on file conventions. x-ref: feedback from #65507 Closes #66232
ForsakenHarmony
pushed a commit
that referenced
this issue
Aug 15, 2024
#66477) Optimizing the static generation for dynamic metadata routes If you're not using `generateSitemaps()` or `generateSitemaps()`, you don't need to change any file conventions. If you're using multi sitemap routes, make sure the returned `id` properties from `generateSitemaps()` don't need to contain `.xml`, since we'll always append one for you. Analyzing the exports of metadata routes and determine if we need to make them as dynamic routes. Previously, users are struggling with the multi routes of sitemap or images. For sitemap, the `.xml` extension in url doesn't get appended consistently to the multi sitemap route between dev and prod. For image routes, the generated image routes are always dynamic routes which cannot get static optimized. The reason is that we need to always generate a catch-all route (such as `/icon/[[...id]]` to handle both single route case (e.g. without `generateImageMetadata`, representing url `/icon`) or multi route (e.g. with `generateImageMetadata`, representing url `/icon/[id]`), only catch-all routes can do it. This approach fail the static optimization and make mapping url pretty difficult as parsing the file to check the module exports has to be done before it. For image routes urls, this approach could help on static generation such as single `/opengraph-image` route can be treated as static, and then it can get static optimized if possible. **Before**: `/opengraph-image/[[...id]]` cannot be optimized **After**: single route `/opengraph-image` and multi-route `/opengraph-image/[id]` are both possible to be statically optimized For sitemap, since we removed appending `.xml` for dynamic routes, it’s hard for users to have `/sitemap.xml` url with dynamic route convention `sitemap.js` . But users desire smooth migration and flexibility. **Before**: In v15 rc we removed the `.xml` appending that `sitemap.js` will generate url `/sitemap` makes users hard to migrate, as users need to re-submit the new sitemap url. **After**: Now we'll consistently generate the `.xml`. Single route will become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`. It's still better than v15 as the urls generation is consistent, no difference between dev and prod. Here's the url generation comparsion All the routes are dynamic which cannot be optimized, we only had a hacky optimization for prodution build multi-routes sitemap routes | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image/[[...id]] | /opengraph-image[[...id]]/ | /opengraph-image/[[...id]] | | sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev: `/sitemap/[[...id]]` prod: `/sitemap/[id]` | Most of the single route will are to get statically optimized now, and the multi-routes sitemap are able to get SSG now | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - | | sitemap.js | /sitemap.xml | - | /sitemap/[id].xml | Next.js will have less overhead of mapping urls, we can easily multiply the urls generation simply based on file conventions. x-ref: feedback from #65507 Closes #66232
ForsakenHarmony
pushed a commit
that referenced
this issue
Aug 16, 2024
#66477) Optimizing the static generation for dynamic metadata routes If you're not using `generateSitemaps()` or `generateSitemaps()`, you don't need to change any file conventions. If you're using multi sitemap routes, make sure the returned `id` properties from `generateSitemaps()` don't need to contain `.xml`, since we'll always append one for you. Analyzing the exports of metadata routes and determine if we need to make them as dynamic routes. Previously, users are struggling with the multi routes of sitemap or images. For sitemap, the `.xml` extension in url doesn't get appended consistently to the multi sitemap route between dev and prod. For image routes, the generated image routes are always dynamic routes which cannot get static optimized. The reason is that we need to always generate a catch-all route (such as `/icon/[[...id]]` to handle both single route case (e.g. without `generateImageMetadata`, representing url `/icon`) or multi route (e.g. with `generateImageMetadata`, representing url `/icon/[id]`), only catch-all routes can do it. This approach fail the static optimization and make mapping url pretty difficult as parsing the file to check the module exports has to be done before it. For image routes urls, this approach could help on static generation such as single `/opengraph-image` route can be treated as static, and then it can get static optimized if possible. **Before**: `/opengraph-image/[[...id]]` cannot be optimized **After**: single route `/opengraph-image` and multi-route `/opengraph-image/[id]` are both possible to be statically optimized For sitemap, since we removed appending `.xml` for dynamic routes, it’s hard for users to have `/sitemap.xml` url with dynamic route convention `sitemap.js` . But users desire smooth migration and flexibility. **Before**: In v15 rc we removed the `.xml` appending that `sitemap.js` will generate url `/sitemap` makes users hard to migrate, as users need to re-submit the new sitemap url. **After**: Now we'll consistently generate the `.xml`. Single route will become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`. It's still better than v15 as the urls generation is consistent, no difference between dev and prod. Here's the url generation comparsion All the routes are dynamic which cannot be optimized, we only had a hacky optimization for prodution build multi-routes sitemap routes | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image/[[...id]] | /opengraph-image[[...id]]/ | /opengraph-image/[[...id]] | | sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev: `/sitemap/[[...id]]` prod: `/sitemap/[id]` | Most of the single route will are to get statically optimized now, and the multi-routes sitemap are able to get SSG now | | only default export | `export generateImageMetadata()` | `export generateSitemaps()` | | -- | -- | -- | -- | | opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - | | sitemap.js | /sitemap.xml | - | /sitemap/[id].xml | Next.js will have less overhead of mapping urls, we can easily multiply the urls generation simply based on file conventions. x-ref: feedback from #65507 Closes #66232
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Link to the code that reproduces this issue
https://github.com/amannn/nextjs-bugrepro-sitemap
To Reproduce
/sitemap.xmlCurrent vs. Expected behavior
For
app/sitemap.tsto be served at/sitemap.xmlinstead of being served at/sitemap. I suspect this started happening after this pull request was merged: #65507Someone else has experienced the same problem and raised it in that pull request.
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.5.0: Wed May 1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031 Available memory (MB): 65536 Available CPU cores: 16 Binaries: Node: 20.5.1 npm: 9.8.0 Yarn: N/A pnpm: 9.1.0 Relevant Packages: next: 15.0.0-rc.0 // Latest available version is detected (15.0.0-rc.0). eslint-config-next: N/A react: 19.0.0-rc-f994737d14-20240522 react-dom: 19.0.0-rc-f994737d14-20240522 typescript: 5.4.5 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Not sure
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local), Vercel (Deployed)
Additional context
This is seems to be working with NextJS 14.2.3. The problem is happening on NextJS 15.0.0 RC 0.
The text was updated successfully, but these errors were encountered: