ALTA Web Site Redirect & Rewrite Setup

This documents how the www.alta.org site is setup so that “.cfm” and “?” aren’t in URLs for SEO purposes, but still are there from the server side for processing both the CF script AND passing URL variables to a page.

It also documents the way URLs are processed when “missing” to determine if it should be redirected to a different page.

Definitions

1.  IIS Rewrite

   • This is a “rule” in the “web.config” file, and happens at the server level BEFORE ColdFusion kicks in.

   • Rewrite rules do NOT change what’s in the browser, they just tell the server what to do with it underneath.

2. IIS Redirect

   • Likewise in the same location, before CF kicks in.

   • Redirect rules DO change what’s in the browser, they kick a full redirect.

3. CF Redirect

   • Similar to #2, but done by the ColdFusion script itself.

   • Depending on what needs to be done, it’ll be via #2 or #3 for different reasons.

ALTA’s Specific Rules

1. Removing .CFM / Rewrite without .CFM (global)

   • If there IS a .CFM in the URL, then IIS full Redirects the browser to the same URL without the .CFM. That will “convert” any URLs to their non .CFM version.

     • This would change “/whatever/something.cfm” to “/whatever/something” which looks like a folder, not a file.

   • If there is a situation where the path can’t be found, as in the URL doesn’t have a .CFM, if that FILE exists instead, then a Rewrite rule kicks in so that the sever actually executes.

     • This takes that “/whatever/something”, sees that the directory doesn’t exist, so then looking for the .CFM file of the same name, and executes it.

     • So “/whatever/something.cfm” is actually executed, but the browser bar stays at “/whatever/something” since that’s what “Rewrite” does, it’s server side only.

2. Having a Path work instead of a URL variable

   • So something like “/whatever/page/ThisCommitteeName” actually needs to be “/whatever/page?ThisCommitteeName”.

   • To do this, we have to specifically code the “web.config” for only the places where it needs to be done, for the Engagement Groups, for example, and then anything else that I run into when parsing through, code has to be added individually for the page. That’ll be for HOP things, news, everything that this needs to be done for.

3. “Removing” the “?” from the URL when it is there.

   • This is basically the inverse of the above, so if there IS a ? in the URL, but we don’t want people to see that, we don’t want that to be the actual page, etc.

   • This is done at the CF level in the script for the specific page. It’s a full redirect so that “/whatever/page?ThisCommitteeName” actually redirects completely to “/whatever/page/ThisCommitteeName” which then kicks in the Rewrite above.

4. Correct URLs in meta data (global)

   • For both the og:url and the canonical link, code’s in place to make sure it’s the “right” version, which is a little tricky due to what the server actually sees versus what we want visually. Sorta hard to explain this one, but it works.

Here are specific examples in the one area I’ve done on the new site, you have to carefully look at the “/” and “?” and such in the URLs before you click on them.

https://www.alta.org/membership/leadership-and-engagement-groups/

• This actually IS a folder, not a file, because there are subpages inside it, so it’s actually executing this script: https://www.alta.org/membership/leadership-and-engagement-groups/index.cfm

• If you do that “index.cfm” you’ll see it redirects to just “index” but we wouldn’t really care about that.

https://www.alta.org/membership/leadership-and-engagement-groups/leadership-resources

• This is actually this script running: https://www.alta.org/membership/leadership-and-engagement-groups/leadership-resources.cfm

• Which you can see removes the .CFM from it.

https://www.alta.org/membership/leadership-and-engagement-groups.cfm?Board-of-Governors

• This would have been our old way of things, where the .CFM is there and the ? URL is there.

• Last round we at least removed the “committee=” portion of things to make it a little cleaner.

https://www.alta.org/membership/leadership-and-engagement-groups/Board-of-Governors

• This is now the full URL to this specifically, which is what the browser will always redirect to, and the meta data will always show.

Built in System for Redirecting “not found” URLs

Whenever the web server can’t find an actual URL, meaning there is no .CFM or other file exactly at the URL requested, it trigger the script “/missing.cfm” which then does a series of things to work through things.

First, note that in the Intranet CMS for Page Management, each “page” is setup with a unique “nav code” which is just a “short code” version of the title. There are then settings for which section and subsection it is for navigation purposes. All of this is used for the dyanmic output of the navigation structure on the www.alta.org web site, but ALSO for redirects.

If we look at a full URL such as this one: https://www.alta.org/membership/my-membership/member-logo

You can see that this is a few “folders” deep. That’s the location of the actual .CFM file as noted above. That file has the nav code that matches it, so it “knows” how to output that pages' content, navigation breadcrumbs, etc. However, this URL will also work to redirect to that: https://www.alta.org/member-logo

See that it’s a shorter version using ONLY the “nav code” as the path. There is no CFM file actually there, so the “not found” script kicks in and takes it from there, eventually getting you to the right location.

NOTE: Browsers cache redirects. So if there are changes made, a reload doesn’t immediately catch it. External Redirect Checkers such as this site can tell you exactly what’s happening: https://www.redirect-checker.org/

Not Found Script Hierarchy

1. Pulls the actual URL and query parameters in the URL that wasn’t found and tries some initial clean up to support some of the situations above. This is the order of what’s done next, once one is hit, it redirects. If it’s not, then it moves to try the next, and so on.

2. If “PortalTools” is in the URL (the old GoMembers user portal) redirect to the REM Portal.

3. If “blog.alta.org” is in the request with a specific article URL, lookup the old URL and redirect to the blog archive output. (The blog used to be in TypePad, and all articles were archived.

4. If a .PDF is being looked for, check that it’s not in the “/media/pdf” folder and redirect to it.

5. Parse through a small set of older URLs that are no longer in use at all, and redirect to their locations manually.

6. Lookup the code in the CMS system’s “Old URLs” which is a place to add previous URLs, nav codes, from the old site(s). If the code’s found in the “Old URLs” then redirect to the new full location.

7. Lookup the code in the CMS systems' “Alternate Codes” which is a similar setup, just a different field for other codes to use.

8. Lookup the URL in the manual redirect system. This is on the Intranet Data Lists section, and is for more complex full URLs, or “shortcuts” for marketing and other purposes where whatever the URL is isn’t part of the Old or Alternate URLs above. https://intranet.alta.org/list.cfm?listeditID=42

9. When nothing else is found in our systems, then filter out a series of “bad” words and script extensions that would never apply to ALTA if not specifically in the URL covered above. In that case, the system just aborts and nothing happens but a blank screen.

10. Finally, if the missing URL isn’t found somewhere, and isn’t “bad” then we log it into the CMS for future reference. This can then be used for monitoring if there is a bot attack, or could also be used to see how people are using the site and not finding what they need.

11. At this point, the note found page displays, which can be seen directly here (all the stuff above doesn’t kick in when it’s hit directly.) https://www.alta.org/missing

Completely Removing a URL

When a specific page/URL/etc. is being completely deprecated and needs to redirect elsewhere, a few different things would be done.

1. Delete the .CFM file itself. If the file is still there, it’ll execute, NOT move into the steps above.

2. Delete the CMS record, which will include the “nav code” so that in the steps above, that page can’t be found in the database.

3. Add a redirect to the “Data Lists” location above.

4. You can see this for “Title Waiver Pilot” URLs there.