Redirects
Table of contents
- 1. Introduction
- 1.1. Intended Audience
- 1.2. Additional information
- 1.3. References
- 2. Status
- 3. Functional Specification
- 3.1.1.1. Approach #1: Redirects are pages
- 3.1.1.2. Approach #2: Redirects apart from pages
- 3.2. Use Cases
- 3.2.1. Functionality
- 3.2.2. Redirect management
- 3.3. Non-goals
- 4. Technical Specification
- 4.1. UI requirements
- 4.2. API requirements
- 4.3. DB Schema
- 4.3.1. Approach #1: Redirects are pages
- 4.3.1.1.1. Upgrade
- 4.3.2. Approach #2: Redirects apart from pages
- 4.3.2.1.1. Upgrade
- 4.3.1. Approach #1: Redirects are pages
- 5. Future improvement ideas and direction
Introduction
Redirects allow MindTouch page structure to be reorganized without the need to update links pointing to them on external sites. When a user clicks a link to a MindTouch page that is now a redirect, the contents of the page the redirect points to is displayed automatically. Redirects are created automatically when a page and its subpages are moved or renamed and can also be created manually by inserting the text #redirect[path/to/target] in the page content. This spec aims to fix and improve the following aspects of the current redirect implementation:
- Performance: When a page and its children are moved, a performance penalty is paid to manage the redirects. This has made move perform poorly when moving 500+ pages. The following happens during a move:
- 1) Redirect pages are created for every moved page pointing to the new titles.
- 2) Redirect pages to current location of moved pages are updated to point to new titles.
- SEO: If a page has several redirects it each is seen by crawlers as effectively a copy of the definitive page's content which reduces its ranking.
- Usability: A cryptic text must be typed into a page to create a redirect making the feature undiscoverable and unintuitive.
- Curation: There's currently no way to see a list of all redirect pages pointing to a given page. This is a problem when restructuring content.
- Curation: Redirects to deleted pages stay in the system and there's no simple way to find and remove them.
- Usability: There's currently no simple way to edit a redirect page to an external URI since the URI is immediately followed.
- Extensibility: There's no way to redirect to a URI which is determined dynamically by scripting.
- Usability: After a page is moved, other pages still link to redirect which is very confusing if an entire hierarchy is moved since links to old locations exist and show up in the browser address bar once clicked.
Intended Audience
Additional information
References
Status
MaxM 30 Jul 2010: The set of problem areas with redirects that I'd like to see improved are described. Functional spec and use cases are still missing many items. Two implementation approaches are discussed
Functional Specification
- Redirects can be made to point to:
- Pages (by a page id rather than title)
- External URIs
Approach #1: Redirects are pages
- Maintain interface via pages for getting a page by title where the title is a redirect. When not following redirect, show redirect as a page XML
- Moving pages creates redirects by page id
- Move is much faster since there's no need to update existing redirects that may have existed to previous titles
Approach #2: Redirects apart from pages
- Redirects can exist alongside a page by same title
- Redirect takes precedence when named same as a page
- Child pages may exist without violating golden rule
Use Cases
Functionality
- User moves a page and its children to a new location. A redirect is automatically created at each previous location pointing to its new location.
- User moves a page and its children to a new location not knowing that the target location is currently a redirect. The move completes successfully and any existing redirects conflicting with the moved pages are removed.
Redirect management
- User wishes to know all the ways to get to the current page. User clicks More->Redirects for a dialog that shows a list of redirects to this page. User may also add and remove redirects on this screen.
- User clicks on an old link to a MindTouch page that is now a redirect and notices that the redirect is not pointing to the correct page. On top of the page is message indicating that a redirect was followed with a link to modify the redirect. User clicks on that link which brings up a dialog box that allows updating the target page of the redirect. User chooses the correct page via search and page hierarchy (just like link dialog) and saves the change.
Non-goals
Technical Specification
UI requirements
API requirements
- Create redirects
- get redirects
- to path
- to page id
- change target of redirect
- delete a redirect
DB Schema
Changes for the db depend on the approach selected for storing redirects
Approach #1: Redirects are pages
This approach requires few schema changes.
table: pages
- page_redirect_page_id (new indexed column)
This new column stores the page id of the redirect target. This allows quick and simple queries for determining which redirects point to a given page.
Upgrade
For each current redirect:
- Convert page title redirects to page id
- Convert external redirects to one of
- Page property
- column? another table?
- leave in page text
Approach #2: Redirects apart from pages
This approach adds a new table for the storage of redirects. The table should be at the least be defined as:
table: redirects
- redirect_id
- redirect_title
- redirect_to_page_id
- redirect_to_url
- redirect_description
- redirect_create_user_id
- redirect_create_timestamp
- redirect_update_user_id
- redirect_update_timestamp
- redirect_delete_user_id
- redirect_delete_timestamp
Upgrade
Each redirect is converted to a row in the redirect table and removed from pages.
Future improvement ideas and direction
- Enter a description for the redirect that would get displayed by the UI before following the redirect (with a timeout value)
- Make a redirect only active after a timestamp
- Temporarily disable a redirect
- Affect all paths under the redirect as well
- Use DekiScript snippet to determine redirect target
- Ex: redirect based on source IP/host/group memberships/language
- Tag page
- What links here
| Images 0 | ||
|---|---|---|
| No images to display in the gallery. |
Copyright © 2011 MindTouch, Inc. Powered by
I think it's important to let a human user know one way or another that the link they clicked bounced them to another location. And the UI needs to allow a way to make changes to the redirect which means it has to know which redirect was followed. The location header in the 301 response can include a query parameter describing which link was clicked. Would that reduce the SEO benefits if the 301s leading to the definitive page had different values of a query param? edited 11:59, 20 Jul 2010
I don't care just for SEO benefits - it's confusing when you start a page under your user page, and then move it to the regular hierarchy; people who hit the old URL still see the old URL, leading them to think the page isn't new or authoritative.
I do agree that it is a little confusing. You do get a message saying that a redirect was followed but it may not be enough. As long as we still have a mechanism to allow users to modify the redirect, I don't see a reason to not use a 301 and have the real page URI reflect what your browser URI reports. edited 13:14, 20 Jul 2010
(P.S. it seems every edit you make triggers the email notification. Thought I was going mad, getting these all twice...)