Homepage Redirect Policy?

Development Documentation
1

Redirects for the Homepage repo are looking complicated. On my machine I see:

$ cat netlify.toml |grep redirects |wc -l
80

Currently redirects are hard to work with, particularly because:

  • the dev instructions don’t provide the netlify-cli, but instead serve the project without redirects enabled for testing
  • I don’t see any tests for redirects
  • there are many of them
  • the paths are sometimes hairy to work with, causing errors

For example, here is a rule:

[[redirects]]
  from = "/nix/manual/*"
  to = "manual/nix/stable/:splat"
  status = 302
  force = true

In this case, the rule is (I think) supposed to redirect URLs for manual pages to their new paths, and in addition, to redirect URLs for manual pages for Unstable things to Stable. (In this case the rule doesn’t quite work, but that is not my focus.)

It looks like there is some heavy URL patching going on:

  • nix/manual → manual/nix
  • unstable → stable
    … and a bunch of other things which apparently have been shovelled around.

One thing I’m wondering about is the 302’s (HTTP Found - a temporary redirect). There are 77 of these. Is it intended to put these pages back or move them to new URLs? If not, I wonder if they should be changed to 301’s (HTTP Moved Permanently). Supposedly it affects SEO etc., but I don’t know what you lose if both sides of the redirect are on the same domain.

Anyhow, my thinking at this point is that since it seems to be hairy and difficult to work with, perhaps the redirects could be simplified. We have bugs with things doing unintended things, especially for rules with :splat, which is easy to get wrong. It may be easier to work with more explicit rules.

I would also consider old site URLs something like deprecated API calls. We could always keep them around for X time, then after consumers have had time to update their links, remove them.

2

@fricklerhandwerk mentioned in the Documentation Team meeting that links shouldn’t break ever, and most links are from static sites which will never be updated. So I guess retiring these redirects eventually is a no go.

3

I’d like to note that this is only my personal, and probably extreme, opinion. I think it’s highly desirable to keep compatibility with links in the wild as long as it doesn’t hinder development, and old layers of redirects don’t make that impression to me – so far.

I wasn’t involved and I don’t have high hopes the commit messages will help finding out why it was done, but probably making them 301 is fine.

I’d support this morally. You asked in the meeting if it even makes sense to spend time on this given @lucperkins works on a rewrite. The redirects should (absolutely should) not be touched by that, so yes, keeping them in order makes sense.

In fact, if anyone agrees that preserving compatibility to 5 year old links on StackOverflow and leading those users to up-to-date documentation instead of to 404 or the top of a 1000 m long page is something we want, I’d even say we should have a CI check that ensures all URLs and anchors stay accessible. Now that surely sounds insane, because that’s what a DB-backed CMS should do, but, to the best of my knowledge, none of those have granular branch-and-merge version control that allows reviews and suggestions. An then, either such tooling to check exposed URLs already exists, because – one would think – it’s something others may also care about, or it’s generic enough to apply for an NLnet grant and work on it in a small, separate project that can be reused.

2 Likes
4

Is it policy to redirect old .../unstable/... URLs to .../stable/... (for manuals)?

I wonder if stuff like this is captured anywhere besides the code.

5

I think unstable links in the manual don’t migrate over to stable links in the manual.

6

I gave it another thought, and this doesn’t sound right. URLs to unstable are the equivalent to references to the master branch. The only thing the redirects should be doing here is pointing from the old URL structure to the new one.

@garbas do you know more?

PS: @HapticBovine thanks for keeping at it, otherwise it would have just have went out of my focus.

1 Like
7 
commit a68a4e2ce0840ee870781f5d9421d95a6fd869eb
Author: Rok Garbas <rok@garbas.si>
Date:   Fri Aug 21 14:27:49 2020 +0200

    change the url of manuals
    
    * add redirects from old urls
    * old manuals are now served as stable
    * and unstable manuals were added
    * <link rel="cannonical" url=".." /> was added not to confuse search
      engines
8

I think that was my mistaken understanding after failing to piece together the intent of the redirects correctly.

My best guess is the URL from my issue is not a valid URL, and that it is mixing things from before and after garbas’ changes.

Details on the issue.

9

Or maybe I’m still wrong :rofl:

10

@fricklerhandwerk thank you for pinging me.

This redirects are there for the old website structure from which we migrated from. There are many links out there that point to the old website url structure and we need to preserve that.

You should never use 301. With 301 that redirect gets cached in the browser of a user and there is now way to invalidate the case. SEO is not affected.

The old URLs we should always preserve. Links to old website will always be there.

I don’t see why we need to simplify these rules? With any longer living website there will be more and more redirect rules. There is nothing wrong with that. On the contrary that is something completely normal.

I do think we could do a better job documenting them.

But I might be missing some important reasons why these cleanup is needed or what is the purpose and final goal of this work.