Is it possible to prepend the domain to relative pathnames?

[astrodomas]

Hello,
Is there an easy way to prepend the given domain name to the app router next-intl Link component?
I want to display the link hrefs as absolute url's.
Writing a wrapper function requires effort, as it needs to be implemented in client-side and server-side components separately to use next-intl provided functions for respective components.

If it is not possible, as next-intl already handles prepending the correct locale to the pathname, would it make sense to extend the feature so that the developer would be able to prepend the given domain name?

current:
<a href="/en/pathname" />
expected:
<a href="https://mydomain.com/en/pathname" />

[amannn]

This could work for you:

<Link href={{pathname: '/about', host: 'mydomain.com'}}>
  About
</Link>

[amannn]

Oh I see your issue now. Yes, if you configure href.host, then the href is treated as an external URL that will not be localized.

I haven't fully understood your use case yet, why you'd want to do this. Do you use a multi-domain setup? Why do you want to include the host? Do you use this for a locale switcher? If you could provide more details that would help me to understand the use case, I can have a look if there's something that next-intl could do here.

[astrodomas]

The usecase here is basically SEO requirements to use absolute urls for href's.
Probably a fix here would be to respect the configuration option passed.

[amannn]

Sorry, I can't follow how including a domain in the assigned pathname is beneficial to SEO. Can you please include details or link to a trustworthy resource that explains this?

Probably a fix here would be to respect the configuration option passed.

The host is typically set for external links, therefore the URL is not touched.

[astrodomas]

Sorry, I can't follow how including a domain in the assigned pathname is beneficial to SEO. Can you please include details or link to a trustworthy resource that explains this?

Probably a fix here would be to respect the configuration option passed.

The host is typically set for external links, therefore the URL is not touched.

https://www.seo.com/blog/absolute-vs-relative-urls-for-seo
https://moz.com/blog/relative-vs-absolute-urls-whiteboard-friday

More info about our usecase. We're currently migrating our ecommerce website to a new stack and we want to keep our urls consistent, in our case it should be absolute urls mainly because of SEO.

[amannn]

Thanks for sharing the links!

It seems like this is the main argument:

Typically, multiple versions of sites exist, the most common being the HTTP and HTTPS versions. Per best practices, your site versions should resolve to a master version to eliminate duplicate content. If your website resolves to a single version, like HTTPS, then using relative URLs for SEO is okay.
However, if your site does not resolve itself — meaning if users click a URL containing HTTP, they’ll visit the HTTP vs. HTTPS page — you’ll want to use absolute URLs for SEO to ensure visitors (and web crawlers) go to your HTTPS website.

If you don't have a main version, e.g. no redirects from HTTP to HTTPS set up, or from without www. to with www., then this sounds like a larger issue to me.

Seems like the SEO experts seem to agree here:

However, it’s worth mentioning that you can (and should) solve this problem by setting your different site versions to resolve to a single version, like HTTPS.

Again, we recommend solving the core issue and setting up the necessary redirects for HTTP to HTTPS.

Also, quoting from above again:

If your website resolves to a single version, like HTTPS, then using relative URLs for SEO is okay.

Looking at a popular website like The Guardian, the links seem to use absolute pathnames, but the URLs are not absolute in the sense that they include a host:

From the perspective of next-intl it's ambiguous whether you're linking to an external website or not when the host option is set, so it could just as well be unexpected behavior if we'd add a locale prefix to such a case. I think for the time being, I'll leave this as-is therefore—I hope you can understand.

If you feel very strongly about this, I can recommend using patch-package to override this part in the built files:

next-intl/packages/next-intl/src/shared/utils.tsx

Lines 14 to 16 in 4c9c130

	if (typeof href === 'object') {
	return href.host == null && href.hostname == null;
	} else {

That way you can still receive updates from next-intl, while keeping your customization.

An other option would be to implement your own implementation for Link from scratch. Depending on which features you use from next-intl, this might be only a few lines of code for simple cases.