Move to blog.ipfs.tech #72

New Issue

2026-10-05T05:12:39+02:00

adam commented

2026-10-05 05:12:39 +02:00

Part of https://github.com/protocol/bifrost-infra/issues/2018

Why

We are moving project website away from ipfs.io, to isolate it from the legacy public gateway, which is blocked in some automated contexts and jurisdictions.
Easy decision is blog.ipfs.tech
Protocol Labs also owns ipfs.blog, so we have an option to migrate to ipfs.blog, if we want

How

add blog.ipfs.tech to existing Fleek and update DNS config at protocol/infra accordingly
- we want to publish to both: keep old domain name working and updated, both regular HTTP and DNSLink
- DNS tracked in https://github.com/protocol/infra/pull/925
update canonical link to point at the new domain
- this ensures SEO and search results are deduplicated and use new domain as canonical one
add JS snippet that detects old domain and redirects to the new one
- this should be smart enough to work with DNSLink, public gateways and Brave
⚠️ ❗ add new domain to discourse (which we use for comment threads)
- Caveat: figure out how we can avoid spamming discuss.ipfs.io with comment threads created fro URLs on new domain
- in the past @lidel wrote additional code that kept old URL for posts created before domain change, we should do the same here
submit new sitemap.xml URL to Google

> Part of https://github.com/protocol/bifrost-infra/issues/2018 ## Why - We are moving project website away from `ipfs.io`, to isolate it from the legacy public gateway, which is blocked in some automated contexts and jurisdictions. - Easy decision is `blog.ipfs.tech` - Protocol Labs also owns `ipfs.blog`, so we have an option to migrate to `ipfs.blog`, if we want ## How - [x] add `blog.ipfs.tech` to existing Fleek and update DNS config at protocol/infra accordingly - we want to publish to both: keep old domain name working and updated, both regular HTTP and DNSLink - DNS tracked in https://github.com/protocol/infra/pull/925 - [x] update [canonical link](https://en.wikipedia.org/wiki/Canonical_link_element) to point at the new domain - this ensures SEO and search results are deduplicated and use new domain as canonical one - [x] add JS snippet that detects old domain and redirects to the new one - this should be smart enough to work with DNSLink, public gateways and Brave - [x] :warning: :exclamation: add new domain to discourse (which we use for comment threads) - Caveat: figure out how we can avoid spamming discuss.ipfs.io with comment threads created fro URLs on new domain - in the past @lidel wrote additional code that kept old URL for posts created before domain change, we should do the same here - [x] submit new sitemap.xml URL to Google

adam closed this issue

2026-10-05 05:12:39 +02:00

adam commented

2026-10-05 05:12:40 +02:00

There is active related work happening on this here: https://github.com/protocol/bifrost-infra/issues/2018

There is active related work happening on this here: https://github.com/protocol/bifrost-infra/issues/2018

adam commented

2026-10-05 05:12:40 +02:00

From an SEO perspective, there's a truism that it's better to have subsites hosted under the same domain as the main website using a path/directry than a subdomain, e.g. ipfs.tech/blog vs blog.ipfs.tech source 1, source2

Google has claimed that it doesn't make a difference, e.g. https://www.youtube.com/watch?v=uJGDyAN9g-g

But it seems that time and time again, people report improvements when moving to the subdirectory/path approach, i.e. ipfs.tech/blog. In fact, I've seen the same improvement in previous projects.

If content and links are split between a subdomain and the main domain, those two entities' overall 'authority' is lower than if everything sat on the main domain (using subdirectories).
That's why it's common to see an uplift in overall organic visibility and traffic (compared to the two viewed separately) when migrating relevant subdomains into subfolders on the main domain.

However, this might be too big a time investment and not so easy to implement, e.g. handling rewrites using Fleek and also making sure all the content is available over IPFS).

If the subdirectory approach is not feasible for us, I would recommend at the very least keeping both ipfs.tech and the blog under the same domain, e.g. blog.ipfs.tech.

From an SEO perspective, there's a truism that it's better to have subsites hosted under the same domain as the main website using a path/directry than a subdomain, e.g. `ipfs.tech/blog` vs `blog.ipfs.tech` [source 1](https://www.semrush.com/blog/subdomain-vs-subdirectory/), [source2](https://www.seo.com/blog/why-subdomains-are-a-bad-idea-for-your-website-and-blog) Google has claimed that it doesn't make a difference, e.g. https://www.youtube.com/watch?v=uJGDyAN9g-g But it seems that time and time again, people report improvements when moving to the subdirectory/path approach, i.e. `ipfs.tech/blog`. In fact, I've seen the same improvement in previous projects. > If content and links are split between a subdomain and the main domain, those two entities' overall 'authority' is lower than if everything sat on the main domain (using subdirectories). > That's why it's common to see an uplift in overall organic visibility and traffic (compared to the two viewed separately) when migrating relevant subdomains into subfolders on the main domain. However, this might be too big a time investment and not so easy to implement, e.g. handling rewrites using Fleek and also making sure all the content is available over IPFS). **If the subdirectory approach is not feasible for us, I would recommend at the very least keeping both ipfs.tech and the blog under the same domain, e.g. blog.ipfs.tech**.

adam commented

2026-10-05 05:12:41 +02:00

Merging blog and website is not feasible imo: historically we did the opposite (moved blog out of ipfs.io because managing them together in a single repo, or later via complex build pipelines a lot of a pain, different teams, too many cooks etc).

As for keeping it separate but picking a new domain name, I don't feel strongly either way ipfs.blog vs blog.ipfs.tech, but one is way easier than another:

blog.ipfs.tech can be migrated under one day, we already have DNS management present, so I can self-service and only need to write some code to handle ⚠️ ❗ in the checklist above
ipfs.blog is blocked by https://github.com/protocol/infra/issues/911, requires involving more infra people. I think we could redirect it to blog.ipfs.tech if it ever gets unblocked, but low priority then.

@BigLep @2color thoughts?

Merging blog and website is not feasible imo: historically we did the opposite (moved blog out of ipfs.io because managing them together in a single repo, or later via complex build pipelines a lot of a pain, different teams, too many cooks etc). As for keeping it separate but picking a new domain name, I don't feel strongly either way `ipfs.blog` vs `blog.ipfs.tech`, but one is way easier than another: - `blog.ipfs.tech` can be migrated under one day, we already have DNS management present, so I can self-service and only need to write some code to handle :warning: :exclamation: in the checklist above - `ipfs.blog` is blocked by https://github.com/protocol/infra/issues/911, requires involving more infra people. I think we could redirect it to `blog.ipfs.tech` if it ever gets unblocked, but low priority then. @BigLep @2color thoughts?

adam commented

2026-10-05 05:12:42 +02:00

For both SEO reasons and credibility/authority via association/domain, I'd recommend blog.ipfs.tech.

For both SEO reasons and credibility/authority via association/domain, I'd recommend `blog.ipfs.tech`.

adam commented

2026-10-05 05:12:43 +02:00

Sounds good to me. Agreed on redirectings ipfs.blog if that becomes unblocked.

Sounds good to me. Agreed on redirectings ipfs.blog if that becomes unblocked.

adam commented

2026-10-05 05:12:43 +02:00

Should be all done: https://blog.ipfs.tech/

Should be all done: https://blog.ipfs.tech/

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/ipfs-blog#72