Redirects and search engines

Two sections of Settings, together because they are the same idea: things served in front of the application, so they keep working when it does not.

Redirects#

Settings › Redirects. An old address that still gets visited — from an email sent last year, a printed leaflet, a search result — sent somewhere else.

Add the path that is still being asked for and where it should go. You can scope a redirect to live only, test only, or both.

Permanent or temporary#

Offered in the words of what they do rather than by number, because the difference is the part that matters and nobody remembers which is 301.

• Permanent — browsers cache it and search ranking moves to the new address. Right when something has genuinely moved for good.
• Temporary — nothing is cached and ranking stays put. Right for a holding page, a campaign, or anything you will undo.

Why they are not in the application#

A redirect exists because an address that used to work still gets visited. The one thing it must do is keep working — including while the application is mid-deployment, while a build is broken, and before anything has been deployed at all. Which is exactly when nobody can fix it.

Served in front, it answers regardless.

Redirects sit after the password gate, so a redirect on a protected application is not a way of finding out what is behind it.

Search engines#

Settings › Search engines. What crawlers are told, per environment.

The defaults are the important part:

• Test is closed unless you open it.
• Live is open unless you close it.

That is almost always what you want, and the failure it prevents — a test copy of a customer's application appearing in search results — is not one you can undo quickly.

robots.txt is served by the platform, so it is right from the moment the application has an address: before anything is deployed, and whether or not a build ever succeeds.