metadata.metadataBase is not set for resolving social open graph or twitter images #57251

TommeZ · 2023-10-23T08:57:12Z

TommeZ
Oct 23, 2023

Summary

Anyone else got this warning message?

⚠ metadata.metadataBase is not set for resolving social open graph or twitter images, using "http://localhost:3000". See https://nextjs.org/docs/app/api-reference/functions/generate-metadata#metadatabase

Additional information

No response

Example

No response

Answered by eMartin94

Oct 25, 2023

Add metadataBase:

export const metadata = {
  metadataBase: new URL('http://localhost:3000'),
  title: 'Title webtsite',
  description: 'this is the desciption'
  openGraph: {
    title: 'Title webtsite',
    description: 'this is the desciption',
    image: 'url/image.png'
  },
  twitter: {
    card: 'summary_large_image',
    site: '@eMartiiin94',
    title: 'Title webtsite',
    description: 'this is the desciption',
    image: 'url/image.png'
  }
}

View full answer

eMartin94 · 2023-10-25T23:08:30Z

eMartin94
Oct 25, 2023

Add metadataBase:

export const metadata = {
  metadataBase: new URL('http://localhost:3000'),
  title: 'Title webtsite',
  description: 'this is the desciption'
  openGraph: {
    title: 'Title webtsite',
    description: 'this is the desciption',
    image: 'url/image.png'
  },
  twitter: {
    card: 'summary_large_image',
    site: '@eMartiiin94',
    title: 'Title webtsite',
    description: 'this is the desciption',
    image: 'url/image.png'
  }
}

15 replies

artginzburg Nov 10, 2023

Sorry if I mislead someone, my bad. Just looked at #49180 to realize that the default value is not being set as I expected in production since it uses VERCEL_URL, which is an auto-generated URL, not the custom domain assigned to the production deployment.

Went to my website to double-check, and yes, the social image host does not look right (I planned for it to be rightshift.dev):

<meta property="og:image" content="https://right-shift-pm2c6zqyo-artginzburg.vercel.app/opengraph-image.png?121e2b7355255853">

So, while using new URL('http://localhost:3000') is a bad idea, not providing any metadataBase is also not a good idea for production as of Next.js 14.0.1

Instead, we can use custom environment variables or just hard-code the production value, which would be OK because apparently metadataBase only takes effect in production (see resolve-url.ts). We cannot use headers() to extract the current URL since they do not exist on build.

LudoLogical Nov 13, 2023

Given what @artginzburg has said, I want to second the idea that this should be opened as an issue. Expecting everyone using an officially recommended approach for including open graph image metadata to either hard-code a production environment variable or see a warning they can't dismiss doesn't seem reasonable to me.

artginzburg Nov 13, 2023

@LudoLogical so what should be the issue exactly? That a better default behavior would be to use the current URL origin as the metadataBase instead of VERCEL_URL, and display no warning in Dev and Preview environments, so that we don't need to set up another environment variable for every new production website?

LudoLogical Nov 13, 2023

@artginzburg I just sent a response, but I've removed it in favor of starting fresh (sorry for any confusion 😅) because I've just realized what you meant by

metadataBase only takes effect in production (see resolve-url.ts)

One concern I had was that devs should be able to use the following pattern when adding metadata with image URLs:

Create the metadata export
Open localhost:3000
Find the <meta> element(s) in <head> and copy the URL(s) from there (notably, these should include localhost:3000 in development)
Paste the localhost:3000/... URL(s) in the browser and confirm that the image(s) are as you expect
Deploy for the first time (note that if metadataBase were applied in dev environments, you would have to do this before steps 3 and 4 since localhost:3000/... would instead be mysite.com/...)

As you correctly pointed out, metadataBase isn't applied in dev environments, so there is no need to do (5) before (3) and (4) and my desired approach works fine.

That said, as I see it, there are two outstanding problems:

The docs do not make it at all clear that metadataBase is ignored outside of production. I would like to propose that we open an issue to clarify them.
We still get those warnings in dev environments. What makes the most sense to me is just disabling them in dev and keeping them in preview and production. I think keeping the existing VERCEL_URL and current URL origin fallbacks for when metadataBase is unspecified is good, but it should probably still cause a warning in production (and maybe in preview too) when you do that.

Assuming both of my suggestions are implemented, the workflow would be very clear:

Testing metadata URL changes is always possible before deployment in dev environments.
Production and preview deployments would complain if the fallbacks have to be used.
- This might cause a little frustration because "it worked fine when I tested it in dev," but clear docs indicating that metadataBase is ignored in dev and definitely not ignored in preview/production should ensure that no one is caught by surprise in the majority of cases. Also, even if it were to cause frustration, the fix would be clear from the docs and would only be encountered once per project (once the metadataBase is specified, it's specified, so you'd have to deliberately remove it to get the warnings again).
Vercel users, users of other managed Next.js deployment services, and self-hosters would all continue to handle any metadata warnings the same way. The existence of Vercel's special VERCEL_URL fallback wouldn't preclude non-Vercel users from simply using the current URL origin fallback.

Thoughts? I must admit that, although I'm somewhat familiar with all of this, I'm definitely not a subject matter expert, so there might be a user persona or an edge case I'm not accounting for.

jsefiani Dec 28, 2023

Did anyone create the issue?

SaiRev0 · 2024-01-10T21:29:32Z

SaiRev0
Jan 10, 2024

⚠ metadata.metadataBase is not set for resolving social open graph or twitter images, using "https://aaspaas-65teeuj9v-sairev0.vercel.app". See https://nextjs.org/docs/app/api-reference/functions/generate-metadata#metadatabase

I have the same issue in dev mode and in production as well. I don't have any metadataBase variable for the URL. So what should I do ?

4 replies

jpainam Feb 4, 2024

@SaiRev0 did you fix this problem?

SaiRev0 Feb 5, 2024

I tried different things but didn't worked for me so at last I added the production URL there, that fixed it metadataBase: new URL('https://abc.xyz')

Aj7Ay Mar 13, 2024

where we have to update this? @SaiRev0

SaiRev0 Mar 19, 2024

@Aj7Ay In your layout.tsx file

theigor · 2024-01-11T16:17:18Z

theigor
Jan 11, 2024

Likewise, I am seeing this in production. A deployment from a few months ago had the metadataBase set correctly and a new prod deployment uses the generated vercel url and is ignoring the base url.

0 replies

jpainam · 2024-02-04T17:29:52Z

jpainam
Feb 4, 2024

Facing the same issue. I have used
VERCEL_URL=https://my_url.vercel.app and

export const metadata = {
  ...metaObject('Appointment'),
};

export const metaObject = (
  title: string,
  openGraph?: OpenGraph,
  description: string = "A default description"
): Metadata => {
  return {
    title: title ,
    description: description,
    metadataBase: new URL('https://my_url.vercel.app'),
    openGraph: openGraph ?? {
      title: title ,
      description: description,
      url: 'https://my_url.vercel.app',
      siteName: '', // https://developers.google.com/search/docs/appearance/site-names
      images: {
        url: 'https://a_valid_amazons3_url.png',
        width: 1200,
        height: 630,
      },
      locale: 'en_US',
      type: 'website',
    },
  };
};

But i still get the error when visiting the page.

1 reply

dvzrd Mar 31, 2024

Am I to understand that we need to set different url variables for each environment?

When overriding the default, we recommend using environment variables to compute the URL. This allows configuring a URL for local development, staging, and production environments.
Ref: https://nextjs.org/docs/app/api-reference/functions/generate-metadata#default-value

What if the app is deployed on Vercel, does that mean the defaults are set automatically? Does this include custom domains as well? Sorry, but the docs aren't entirely clear on this. Here's what I ended up doing on one project, but I would rather avoid the extra config files if I can.

In next.config I added basePath env like this:

const basePath = process.env.BASE_PATH ?? '';

module.exports = {
  ...rest of your next config,
  env: {
    basePath,
  },
}

Then I setup a metadata config with a url value like this:

export const appMetadata = { 
   ...rest of your metadata config
   url: process.env.basePath || 'https://domain.com',
}

Then in app/layout I set the metadataBase along with other metadata defaults for the app:

 metadataBase: new URL(appMetadata.url),

There's probably a more optimal way of doing this, I'm sure. Maybe using @t3-oss/env-nextjs and zod instead of messing with the next config. Seems like there's a better solution to this, would be nice to have an official example.

Does anybody have another solution for setting metadataBase with environment variables that they wouldn't mind sharing?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

metadata.metadataBase is not set for resolving social open graph or twitter images #57251

{{title}}

Replies: 4 comments 20 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

metadata.metadataBase is not set for resolving social open graph or twitter images #57251

Summary

Additional information

Example

Replies: 4 comments · 20 replies

Replies: 4 comments 20 replies