Error: missing metadataBase

[abstractvector]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: Ubuntu 20.04.0 LTS Sun Feb 12 2023 09:39:20 GMT+0100 (Central European Standard Time)
Binaries:
  Node: 16.14.2
  npm: 7.17.0
  Yarn: 1.22.19
  pnpm: 7.13.6
Relevant packages:
  next: 13.1.7-canary.10
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Metadata (metadata, generateMetadata, next/head, head.js)

Link to the code that reproduces this issue

https://stackblitz.com/edit/vercel-next-js-dsf3tr

To Reproduce

Define a relative canonical URL (metadata.alternates.canonical) on a page without specifying metadataBase in that same page.

Describe the Bug

If a relative canonical URL is specified in the metadata of a page, an error is generated during build:

Error: missing metadataBase

This occurs even if the metadataBase is included in the metadata exported from a parent layout.

This issue does not happen in 13.1.7-canary.7 and starts with 13.1.7-canary.8.

Expected Behavior

A relative URL should be allowed for a canonical URL without the metadataBase being specified anywhere in the metadata export hierarchy.

But if the metadataBase is specified in a parent metadata export (e.g. a layout) then it should be respected and used.

Which browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

next run build

[michaelcummings12]

Experiencing the same issue in 3.1.7-canary.9

[abstractvector]

This is still an issue in 13.1.7-canary.17. In my opinion, there are two things that should be changed here:

1. A canonical URL should allowed to be a relative URL and hence metadataBase should not be needed
2. If a metadataBase is provided in any parent metadata object (e.g. the root layout) it should be respected by all children

If people are agreed with the above, I can attempt a PR to solve it.

[huozhi]

The canonical url is required to be absolute url so you need to provide a metadata.metadataBase (mostly including the host info) to resolve it as a absoulte url.

From https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
Use absolute paths rather than relative paths with the rel="canonical" link element. Even though relative paths are supported by Google, they can cause problems in the long run (for example, if you unintentionally allow your testing site to be crawled) and thus we don't recommend them.

We've updated the error message with more information, but still polishing it and will add docs link into the error message soon.

[abstractvector]

@huozhi Google is not the only consumer of canonical URLs, and the HTML spec does not require them to be absolute.

The target (canonical) IRI MAY:

o Specify a relative IRI (see [RFC3986], Section 4.2).

Source: RFC6596: The Canonical Link Relation Section 3

While I appreciate the rationale, I would argue that it's over-opinionated to restrict the usage to Google's recommendation.

However, even if one wishes to use an absolute URL, the issue here remains that the metadata.metadataBase specified on a parent metadata object is not used, meaning it must be individually specified on every single route.

I believe the desired behavior should be that if a metadata.metadataBase has been specified anywhere in the parent metadata tree, it should be used to create an absolute URL. If not, a relative URL should be returned.

[huozhi]

Fixed in 13.2.3

[ChristopherNowlan]

I got the issue today using 13.2.4 on vercel
Error: metadata.metadataBase needs to be provided for resolving absolute URLs

[huozhi]

@ChristopherNowlan can you tell which url you're getting this error, there're some urls required to be set the metadataBase as the host for the url. For example og image and twitter image needs to be absolute url. Or can you share a full reproduction?

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.