Improved SEO with canonical link headers

Hi all,

Next Monday, March 30th, we’re going to make a change to improve SEO in sites that have configured a custom domain. I want to tell you a little bit more about it before we roll it out.

Every time you create a new Netlify site, we assign a subdomain for it in our primary domain, netlify.com , for example happy-wozniak-23hdl3.netlify.com . As you might already be aware, on April 14 2020, we’re changing that domain to netlify.app , so that previous example will become happy-wozniak-23hdl3.netlify.app .

When you configure a custom domain for a site, the original subdomain on Netlify’s domain still works — we keep it available for troubleshooting purposes. However, this is not very SEO friendly, and many of you have expressed concerns about Google and other search engines penalizing you because of that. There are several ways to address this problem, and I want tell you about a couple of them before I tell you about how we’re helping you starting next Monday.

The first solution is to use our redirects to send traffic from your Netlify subdomain to your main custom domain. This is a good solution, but it’s a little bit fragile because you need to add more configuration to your site. If you decide to change your memorable subdomain to something even more memorable, like happy-hamilton , you’d have to remember to change the redirects file too.

The second solution is to add canonical links to your html pages. Adding canonical links is the standard way to inform web crawlers to index content only from a specific domain. We recommend people to use this solution because it’s standard, regardless of whether you use Netlify, or any other service. It’s also integrated in many static site generators, so maintenance is easier for you if you use any of those tools. Besides being accepted as html elements, canonical links can also be presented as HTTP response headers.

Since we know that many people don’t add canonical links to their html pages, we’re going to help you with it. Next Monday, we’re going to release a change that will add a new Link HTTP response header to prevent crawlers from indexing content in your Netlify subdomain if you’ve set a custom domain for your site. We will only do this when we receive requests to those Netlify subdomains and your html pages don’t include a a canonical link already. That header will look something like this if you use cURL to send a request to your Netlify subdomain:

> Link: <https://your-custom-domain.com>; rel="canonical" 

If your site is proxying requests through another Netlify site, we’ll use the domain that will show in visitors’ address bar in that response headers. If you’re proxying through a different CDN, like Cloudflare, Fastly, or Cloudfront, we recommend you to add canonical link tags to your html, since we cannot detect when traffic is coming through those other providers.

If your site has several alternate domains, besides a specific custom domain, we’ll use the primary custom domain as the canonical domain.

If you want to modify or disable that behavior in any way, we recommend you to set canonical links in your html pages, which is a standard SEO practice. You can also override that header by using Netlify’s headers configuration.

Don’t hesitate to leave a comment in this thread if you have any questions about this change. We’re here to help.

5 Likes

Hi @calavera,

It’s very nice to see that you and your team care about SEO.

I’d like to ask if and how setting a rel="canonical" meta tag in HTML affects you adding a Link header? We’ve already set up all needed tags in our sites. I’d imagine that in case someone set a canonical in HTML, Link header should not be sent, or at least the meta tag value should be used. Is it the case in your implementation?

The other question is more general: is there some kind of staging environment where we can test how this and similar changes will behave on our sites? This would allow us to make sure that all big changes are not affecting our websites in an undesired way. And in case something is wrong, we could either make proper changes on our end or get back to you with a precise feedback before final release, instead of sending tickets after the release :slight_smile:

1 Like

Regarding your first question, I think this is what you’re looking for:

And, I really like the idea proposed in your second question.

Cheers.

Hi @dmgawel,

is there some kind of staging environment where we can test how this and similar changes will behave on our sites?

For major changes, we have beta programs to allow customers test features before the final release. Additionally to beta programs, we have several mechanisms to segregate how features affect our customers, and we always stagger changes during releases. Our own properties are usually the ones that get new changes first, so we can validate that we’re happy with new changes. But, we’ve enabled features for specific customers before release date, so they can also test them.

We don’t consider this a major change, since it only affects sites in very specific scenarios. However, we could have definitely worked with you if we’ve seen this message earlier. Don’t hesitate to reach out at any time in the future, we’re always happy to help test these things.

So, if we’re not doing anything to help SEO but we are using a custom domain, does that mean we don’t have to do anything? Netlify’s fix for the Link header for netlify.app domains will, essentially, solve the problem? Or would you recommend that, in addition to Netlify’s fix, we still add rel=canonical tags to our generated HTML pages?

Correct, @jimniels- no further action needed! If you check out your response headers when going to your Netlify subdomain (that redirects to your custom domain; this change does not affect headers when you navigate directly to your custom domain), you should see the Link header there.

1 Like