Skip to content Skip to site navigation

Web Address Change Issues and Answers

The to change has been completed. If you find any issues with your website due to this change, please contact us at

1. Testing your address — vanity URLs, navigation, and website functionality

The easiest way to tell how your website will be affected by the change is to simply type the URL into your browser and see what happens …

  1. If you have a vanity URL, determine which type it is by looking at the address bar after the site loads (if not, skip to step 2):
    • If your vanity URL still shows in the browser’s address bar, then the URL is a proxy-type URL and no changes will be visible to your visitors. No action on your part is required for your site to continue to work.
    • If the vanity URL changes to a URL after the site loads, then the URL is a redirect-type URL. After the switch, these URLs will automatically redirect to Your website will most likely be OK, but you should test it to make sure …
  2. In the URL that appears in the browser’s address bar, replace “www” with “web” and refresh using the resulting URL (the new system is in place, so you can do this now).
  3. Test your site’s navigation by hovering your mouse over the various links to see where they point …
    • If they point to, then the links on the website are relative (i.e., not hard-coded to and will point to the correct URL after the change.
    • If you loaded the page using but your navigation links point to, then your action is required to make these links work after the change:
      • If the site is a WordPress site, change the “home URL” setting to a address.
      • If the site is a static-HTML site (e.g., Dreamweaver), update the link URLs manually so that they are relative; i.e.,
        Relative link (will work): <a href="/about/index.html">
        Fixed link (will break): <a href="">
      • In addition to your <a> tags, check for references to in your <img> and <script> tags, as well as in linked CSS style sheet files, and update as needed.

2. What University IT will do on the day of the change

  • Implement a global redirect so that all non-homepage URLs starting with will redirect to
  • Update proxy-type vanity URLs to work with (No action is necessary on your part and your visitors will not notice the change.)
  • Implement changes so that redirect-type vanity URLs automatically switch to point to (You should test since the switch will be visible to website visitors.)
  • Begin publishing Formbuilder (Web Forms Service) forms to URLs instead of (You should update any links to them, but they won't break - because of the global redirect above)
  • Change scripts running on the Scheduling service that address to address instead.
  • Patch Drupal 6.x sites running on and using the WebAuth module (version 2.56 or earlier) so they will continue to work.

3. What University IT will not do on the day of the change

  • We will not update your hard-coded references to; i.e., we will not update your links.
  • We will not update appearances of URLs in your content.

Your links to URLs will not break because University IT will put a global redirect in place. However, to save your visitors an extra redirect you should update your links to point to when appropriate.

4. Google Analytics

University Communications has tested Google Analytics and it appears the change to the URL from to will not affect the collection of data.

5. Google Custom Search

If you use Stanford’s Google Custom Search on your website, you do not have to update its reference to

For example, you might have a line of code that reads:

<form action="" id="cse-search-box”>

You don’t have to update that line. After the change, the reference to will remain correct.

However, if you are limiting your search results based on a URL, you will need to update that reference. For example, if you have some code that reads:

<input type="hidden" name="as_sitesearch" value=""/>

You will need to update that reference to cover both www and web, at least temporarily.

<input type="hidden" name="as_sitesearch" value="*"/>

The * is a wildcard which covers URLs at both and

Eventually, Google will re-index all your pages using When that happens, you can substitute the * with "web".


6. Google Webmaster Tools

Changes of address (www to web), preferred domain, and other features (like crawl rate) in Webmaster tools are only allowed for root level domains. Therefore, any accounts you have created using addresses will stop connecting to those websites once the change to goes into effect. You will have to delete those accounts and set up new ones using addresses.

7. Facebook “likes”

The Facebook “like” button code can use a data-href value that specifies a particular URL. If that is added, the code should be left alone and not changed to or the page will lose its likes. On the other hand, if the data-href value is left blank, Facebook will use the current URL of the page. In that case, the page will lose its likes as it changes URL. To fix this, a data-href value should be added to match the original URL.

The following code will work after the transition (although the URL liked will be the www version):

<div class="fb-like" data-href="" data-layout="standard" data-action="like" data-show-faces="true" data-share="true"></div>

The following code will not work after the transition (the number of likes will reset to 0 because they are associated with the URL:

<div class="fb-like" data-layout="standard" data-action="like" data-show-faces="true" data-share="true"></div>

8. Twitter “tweet this” button

The “tweet this” button from Twitter defaults to using the URL of the page, but you can select a specific URL when creating the button code.

If you used a specific URL in the “tweet this” button code, the number of tweets will remain the same and any new tweets will use the old URL. If no specific URL was used in the code, the number of tweets will reset and any new tweets will use the new URL.

9. Web Forms Service — “Formbuilder” forms

University IT will update forms created by the Stanford Web Forms Service so that they will load correctly from after the change. In addition, we will put redirects in place so that visitors addressing forms via old URLs will be redirected to the new URLs.

If you link to your forms from other pages, you should update those links to save your visitors a redirect. If you don’t update your links nothing will break, but if you do your visitors won’t have to go through a page redirect before your form loads.

If you have included content in your forms that points to or mentions a URL (other than the Stanford Homepage and related high-level pages), you should update those links or content to point to

You can check to see if you have created or been granted administrator privileges to forms that use this service by visiting If no forms are listed there, then no action is required on your part.

10. Drupal 6.x websites with WebAuth version 2.56 or earlier

Websites running WebAuth version 2.56 or earlier store the URL of the site inside a file ( If that file were to remain unchanged, logins would fail with endless redirects. If you run such one of these sites, University IT will patch this file for you on the day of the switch.

Drupal sites running newer versions of the WebAuth module are not affected.

You can check the version of WebAuth you are using by going to the Modules page on your Drupal 6 site. This page is found under <your-site-url>/admin/build/modules.

11. JavaScript and Ajax

If your website uses JavaScript to connect to URLs, the code might need to be updated to use even after the global redirect is put in place:

  • Because of browsers’ same-domain policy, requests from scripts to a server are blocked when loaded from a different server. Therefore, things that worked when your script was loaded from and accessed resources will stop working if the script is loaded from but still tries to connect to University IT has scanned JavaScript files hosted on to identify scripts that are likely to break and will contact the owners of those scripts individually.

12. File location in AFS will not change

The location of your website code and assets in AFS will not move as a result of this change. They will remain in the WWW or the cgi-bin directory or your AFS space.

  • If you manage your website’s files by using SFTP and by connecting to a shared machine such as (through a program such as SecureFX or Fetch) those settings will remain the same.
  • If you manage your website’s files by using WebAFS or OpenAFS, you will not need to change your process.

13. Changing outgoing links

It’s likely that your website links to other websites at Stanford. If those other websites change their URLs, you’ll want to update your links to them to save your visitors an extra redirect. To find links to sites that will be affected, look for links that:

  • Start with
  • and
  • Either point to /dept, /group, /class or ~sunetid (personal) web spaces

If you find such links, you should change the www portion to web. For example, a link to would change to

14. Updating your WordPress URL

If you are running a WordPress site and you’ve noticed that a lot of internal links (archives, permalinks, etc.) use, you can update the vast majority of them with a simple configuration change. Here’s how:

  • Log into your WordPress site
  • Navigate to Settings > General
  • Update your WordPress Address (URL) to use web instead of www.
  • Update your Site Address (URL) to use web instead of www.
  • Save your Changes

WordPress will update its internal links to use the new address.


Last modified July 12, 2021