Changes coming to Netlify site URLs: .com to .app

Starting April 14, 2020, sites without a custom domain are being moved from site-name.netlify.com to site-name.netlify.app . New websites will also have URLs ending with netlify.app by default. Custom domains set on old, or new, sites will behave in the same way as before!

It’s important to note all of your existing sites will continue to operate properly using their current URLs.

Why? We’re investing in the security and stability of our infrastructure, and this step helps in our efforts to enhance those.

There’s no action required on your part , but we wanted to inform you well ahead of the change in case you have any questions. Additional details are provided below if you’d like to read more. Thanks for being part of the Netlify community!

Will my current sites continue to work?

Absolutely. Any sites already deployed to site-name.netlify.com will continue to operate, just as they do now. Traffic to any site-name.netlify.com address will be forwarded to site-name.netlify.app seamlessly and automatically, using an HTTP 301 redirect. (This tells browsers and search engines that the site has moved, so they know the new location.)

Importantly, we have no plans to ever stop forwarding netlify.com addresses or force a migration. We understand your established domain names and inbound links to your site are important to you. After the update, links to your sites will continue to work, just as they do now. The only change will be that netlify.app will display in the URL bar, whether visitors click on a link or type your site name in directly.

Will this impact my SEO?

No. Forwarding traffic to a new domain extension using a 301 redirect is a proven technique that search engines are well aware of. Your inbound links will not be affected. Your search engine rankings will not be affected.

What if I have a custom domain?

There will be minimal impact to sites with custom domains, and almost certainly no need to update your DNS records. This is true whether you purchased a domain through us or brought it with you from another provider.

Will my site take longer to load?

It takes just a couple of milliseconds to direct a .com URL to .app . Your users will not perceive any additional load time. And since browsers cache 301 redirects locally, there will be no speed impact for page loads after the first connection.

What about HTTPS?

We’re doing our part for a more secure web. Every Netlify site deployed uses a free certificate from Let’s Encrypt. Your certificates will continue to work and your sites will continue to be encrypted with no action required.

Do I need to update my site or application?

In most cases, no. This change is very unlikely to impact the way your application functions, as all requests will automatically be forwarded to netlify.app on your behalf.

What about new sites?

Any site you deploy after April 14, 2020 will receive a shiny new .app URL that you’ll see displayed in the Netlify dashboard. However, for simplicity’s sake, even new sites will be forwarded to the right place should anyone mistakenly type the netlify.com domain. We want things to be as simple and seamless as possible.

What if I use a proxy in front of Netlify?

Since Netlify operates as a global CDN, we don’t encourage customers to use proxies or services like CloudFlare in front of Netlify. Using a non-Netlify proxy isn’t a configuration we officially support. (For more details, read the community post ‘why not proxy to Netlify.’) If you do need to use a third-party proxy, you will want to carefully test your application after the migration. Some proxies expect content returned and won’t be successful navigating the 301 redirect.

What if I have questions or concerns?

Let us know in the thread below and we’ll be happy to talk through them with you :slight_smile:

8 Likes

When can we transition our sites from .com to .app?

1 Like

I am not sure that there will be a customer-initiated migration - I think it will be the case that we migrate everyone on the 14th of April all at once. More to come as things develop, but that is our current plan.

2 posts were merged into an existing topic: Redirect does not work, results in “page not found”

OK, I’ll mark it in my calendar. I’m going to want to change the canonical references, sitemap URLs, etc., to match the new scheme and avoid the redirect.

1 Like

What if we are using a 3rd party DNS and our custom domain’s ANAME record points to site-name.netlify.com. Will your redirect work in that scenario or do we need to change our ANAME when you migrate to site-name.netlify.app?

If we need to change right away, do you have an anticipated time of day that the change will take effect?

2 Likes

This is a salient point and one that I think the Netlify team have overlooked. Any .netlify.com domains that have rel="canonical" references or hard-coded XML sitemaps that stipulate the .com domain could see an impact to their SEO. I think this should point should be added/amended to the customer information sent out - there’s enough time for people to plan to make those changes at the time of the switch over cc: @fool

Like @gregraven I’d like to update my content with the new URLs before the big cutover date. It would be nice if site-name.netlify.app could begin working before April 14, before Netlify starts responding to all site-name.netlify.com URLs with HTTP 301s, in parallel with the old .com URLs.

(I use Netlify to publish both normal web content and structured data for FOSS software clients – data that references full netlify.com URLs. Testing the FOSS client support for 301 redirects won’t be fun – I’d rather just get my new URLs working now, update my structured data, and encourage users to start transitioning their client configurations to be more certain of avoiding problems.)

Thank you.

I would love to know if this is going to affect to customs domains pointing to site-name.netlify.com as @mrcycling has asked.

1 Like

Hello, thanks for the update.

Can I ask what the security reasons are for this change? I’m about the jump into a similar typ of decision.

Cheers,
—Koen

We are moving hosted sites to netlify.app so that only content that we control will remain on netlify.com. This ensures that our main domain will no longer have content that is not under our control.

2 Likes

Heya folks, a few more details:

  • @lpuerto and @mrcycling - no, will not affect DNS (will continue working with existing settings at rollover time, regardless of whether we or someone else hosts it). We might have advice about reconfiguring and certainly our docs will update to the new hostname format since we’ll want things to be as obvious as possible.
  • @peter1 - no updates should be needed, so we’re not planning to have general purpose testing open beforehand. We’ll definitely post in this thread as soon as it happens so you can adjust then. If you have a special configuration, please feel free to describe it and if it is not something we’ve already tested we’ll try to work with you to test it before rollout time.
  • @seriocomic - thanks for that suggestion, we’ll add it to the things to investigate before the rollover!
1 Like

Thanks a lot for the info. I re-read later the email and realized that there were stated that those services weren’t going to be affected.

Understandable, thanks for the info. One followup question: What are the reasons you want to keep content on the main .com domain under your control? What are examples of issues?

Lots of reasons, but a big one among them is that we’d like to leave the public suffix list, which we are on due to hosting millions of customer websites on *.netlify.com along with our own - we can’t currently share things like cookies between our *.netlify.com properties (www, app, community for instance).

1 Like

A post was split to a new topic: Redirect does not work, results in “page not found”

Thanks for the extra info! :+1:

1 Like

Interestingly I am still getting a .com Domain without 301 forward:
nisas-alte-sachen.netlify.com
I mean I do not really care about it but it’s just as a hint that it looks like there is something wrong :wink:

This is going to be implemented next month, not already :slight_smile: