7 Redirects

Redirects enable a substitute page to be displayed instead of the one specified in the url a visitor used to access the site.

Warning

Do not use this page unless you know what you are doing.
Some redirects could make your site or parts of it inaccessible.

This page allows several types of redirects to be performed. Some management operations, like renaming a non-hidden article or category, automatically create a temporary redirect valid for four weeks. Use this page to extend it, make it permanent or delete it if no longer needed. Expired redirects are automatically deleted after four weeks.

However, if needing to create redirects as a result of consolidating or splitting articles, carefully map out all the changes that have been (or to be) made, and carefully make a list of all the corresponding redirects to be created. Perhaps break the task down into sub-groups that can be planned, mapped and implemented independently. There can be unintended side effects, so if need be, get help from someone who is familiar with redirects to help you do the mapping, or at least check your intended redirects.

Warning

If wanting to redirect the whole site, use the All redirect type here rather than the cPanel option, as using the latter will prevent you from logging in to use the manage pages, which are excluded from any redirects created here.

The types of redirects, in checking order, are:
#	Type	Description
1	Explicit	A specific article/category or feed is replaced with another. Both paths must end with a `/`. Automatically created when an article or category is given a new Headline/Heading, along with being `Enabled`
2	Replace	Replace the start of the path with another, allowing partial matches by what is not included in the match. Works best with articles and categories with well-structured names
3	Source	If matching to the start of the URL, redirect to a single URL. For redirecting multiple URLs to a new structure
4	All	Catch-all base URL for pointing all URLs to a new domain that has the same structure. Do not end the domain name with `/`, so that the existing path can be appended to it. No From field shown

The fields available for editing a redirect are:
#	Name	Description
1	From	If the URL starts with this path, the redirect is actioned, and all others ignored. Not shown for All type
2	To	If From matched the URL, this is used to build the redirect path according to the type. If `~`, no redirects are done and checking stops, allowing specific exemptions for more generic redirects types that follow
3	Type	Whether the redirect is permanent or not. For `Permanent (301)` redirects, browsers will update their internal URL favourites to use the new URL, and search engines will transfer any ranking for the old URL to the new one
4	Expiry	Date redirect will be disabled. Master manager can extend by set periods
5	Status	Whether enabled. Manually-created redirects are `Disabled` by default
6	Delete	Delete the redirect. Only shown to the master manager
7	Remove all	Delete all redirects of the type. Only shown to the master manager as the last row of the table

Only the first part of the URL is altered by the redirect, leaving any included locale or accessibility values intact, so that users experiences are consistent for redirects to local or remote Smallsite Design sites. The exception is for the Source type, where if /-/ is included at the end of the To field of the type, the locale current at redirection time will replace the -, and the current accessibility setting is added.

The default Type is Temporary (302). Leave as that until after the redirect has been thoroughly tested, as any errors in the redirect definition if the Permanent (301) option is used may result in pages being inaccessible to visitors as their browsers remain locked onto the erroneous new URLs. No actions at the site end will correct those permanent browser favourites changes.

While the Permanent (301) option will supposedly result in search engines transferring page rankings to the new URLs, that only benefits really popular pages. Without that option, search engines will recreate the rankings for the new URLs as visitors stay on them rather than the old ones.

Note that:

a.Enabled non-expired redirects are indicated by a light orange background to the first cell of their row.
b.All paths are typed in, rather than being selectable, because either the From or To paths may not actually exist at the time of creating or editing the redirect.
c.The From field for an Explict, Replace and Source type must start with /art/, /ars/, /cas/, /cat/, /feed/ or /sit/.
d.The redirect is actioned for the first match in the order listed, ignoring all others after. For example, if both Explicit and Replace types are specified, and a path matches one of the Explicit types, that redirection will be used, ignoring any of the Replace types.
e.For all but the All type, if a ~ is used for the To path, no redirection will occur for matches to the From path, thus allowing specific exemptions to a more general redirection following.
f.If a new redirect's From or To paths match to any earlier redirects' paths, those earlier redirects are deleted so that no redirect loops are created, which could bog down the site.
g.The Replace and Source wild-card types are best suited to when well-structured Headlines/Headings are used.
h.All but the All type can redirect to external To URLs though they must use the secure https scheme, unless other non-https schemes have been specified in the Additional schemes field of the Settings section of the Settings page.
i.The main home page, while it may have been put into the browser as a path of /, is converted to /art/h-main/ before redirects are checked, so the root of the site can be specifically targeted for redirection.
j.Smallsite Design automatically redirects URLs with the insecure scheme http to the secure https well before checking for redirects, along with other measures to prevent changing to an insecure scheme.

Some examples of redirects are:
#	Type	Examples
1	Explicit	From: `/art/a-about/` To: `/art/a-about-me/`
2	Replace	From: `/art/p-write-` To: `/art/p-create-`
3	Source	From: `/art/a-element-` To: `/cat/elements/` (same site), or `https://newdomain.com/cat/elements/` (new site)
4	All	To: `https://newdomain.com`

Virtualisation

△

If trying to make a Smallsite design site cater for a lot more content, redirects can help virtualise much of the content.

While content could be spread across a lot of sites, including subdomains, it may be better to make all content seem as if it is on the same site. This is done by using Replace redirects to sent requests for particular content to another site. This will be considerably simplified if those different content pages IDs all start with the same text.

For example, if wanting to redirect all content of a car sales site, https://car-sales.com, related to Ford products, to a subdomain ford of it, suitable redirects are:
From: /art/a-ford-, To: https://ford.car-sales.com/art/a-ford-
From: /cat/ford-, To: https://ford.car-sales.com/cat/ford-.

This would require all page headlines and category headings start with Ford followed by any non-alphanumeric character. Of course, other article types would require their own redirects.

The limitations of this arrangement are:

a.The redirection is to an external site, so will be formatted as such, usually by italics.
b.The internal search only includes the non-virtualised content. Using an external will still limit the search to the current site.
c.Cards and catalog items cannot point to external sites. Using a diagram element element with boxes with links over overlays with background images can provide navigation across the combined sites. These would be placed on home or other navigation pages. To maintain a common look across all sites, those pages, or an article with all the diagram elements, can then be imported into the other sites, and the links in them edited to suit the new location.
d.The Subsites page will not have links to non-site subsites, but the universal navigation solution in the previous item may mitigate that.

To be successful without such hiccups, the content in different sites should be independent of each other to a large extent. For a large body of knowledge, it may be better to have a base site that covers the basics and some administration, rather like the multi-focus site topology for subsites, and not pretend that it is all one site. The locale and accessibility continuity can still be used between them. A different team could look after each, while making them all have a consistent structure across sites.