New and updated websites at BU are prepared on a staging network prior to a public launch. Please review the linked workflows and guidelines below to ensure a smooth and successful launch of your website.

All new/updated website launches must comply with the University’s Website Policy, which includes adherence to the University’s Minimum Web Accessibility Standards. All website editors are responsible for publishing accessible content. Follow these 10 Essential Tips for maintaining accessible website content.

Workflow and Diagrams of Staging Sites

There are two workflows for staging new websites in BU WordPress.

  • NEW, BLANK SITE: New blank sites are created in BU WordPress on the staging server. You get a few default pages (home page, contact page, etc.) and an empty media library. This workflow is used for brand new sites. This workflow is also used if you are replacing an existing site and you want to do the migration and reorganization of the site’s media and content yourself.
  • CLONED SITE: If your site is already in WordPress, we can clone your existing site — everything is copied (pages, posts, media, etc.). This allows you to edit, re-organize, and/or redesign your existing site, change your site’s theme or implement mobile theme options. It is important to remember that from the moment your existing site is cloned, your staging site is a completely separate site from your live site (with a completely separate media library).
    • If your site is updated frequently it is important to note the implications of working on a point-in-time clone of your site. New content like frequent news posts, form entries, and comments will continue on your live site but will not be copied to the cloned site. You will need to minimize edits during the staging period and/or coordinate that all edits be made on both live and staging sites to keep them in sync. You may need to export form entries from your live site before re-launch. If you have questions, ask us.
    • View the workflow diagram for staging a cloned site.

General Guidelines

  • All old sites that are replaced are archived by IS&T. Access to archived copies is restricted to site administrators. If you need access to an old version of your site, please submit a request.
  • Other than working within you staging site do not externally link to, publish, or share a “-staging” web address. This is a temporary URL only for staging and will not be accessible after your site is launched. We do not install redirects from old “-staging” URLs to live sites.
  • Staging sites that have not been edited in over two years will be considered abandoned and are subject to deletion.

Accessibility

Media Content

  • All images, documents, presentations, and other media content must be copied into the Media Library of your staging site, and you must link to the content in the new location.
  • Do not link to images, documents, or any other media content on your old site. Remember — the staging site, and it’s media library, will completely replace the old site and the old site’s media library.

Links

  • You are responsible for updating your links when staging a new site for launch.
  • When linking to other pages on your staging site, it is OK to use the staging URLs (www.bu.edu, sites-staging.bu.edu, etc.). The “-staging” links are automatically replaced by our launch scripts when the new site is launched.
  • Do not link to pages on your old site. Remember — the new site will completely replace the old site.
  • If your old site is not a WordPress site, chances are many of your links are pointing to specific .html files. No links to WordPress pages end in .html, so when staging a new site you will need to update these links accordingly.

Search

  • Staging sites are not public content, so search indexing is blocked for the entire staging network.
  • Search does not work on staging sites.
  • Search will work after your new site goes live, but some search results will show old URLs. It usually takes several days for search engines to re-index your content.

Launch Requests

  • Please allow adequate time and plan accordingly when requesting the launch of your new WordPress site.
  • You can request a site launch from the IS&T help portal with the Launch WordPress Site request form..
  • Depending upon ticket volume it may take IS&T 3-5 days to review and schedule your site for launch.
  • If you want to request a specific date for launch, you should submit your request at least a week in advance.
  • The Web Team reviews all sites before they are approved for launch. In order to be approved for launch a site:
    • Cannot have “coming soon,” or “under construction” pages. Please set these pages to draft status, and you can publish them when appropriate content is ready after the site has launched.
    • Cannot have blank pages. All pages must have appropriate content. If the page in question is a landing page for a section of child pages, at a minimum you should write a short paragraph summarizing the section.
    • Must work fully with mobile browsers. If anything is broken when browsing with a mobile device, the site cannot be launched. Test your site with a mobile phone browser.
    • Must have no severe broken link problems. Site review includes the IS&T Web Team running a link report on your site. If you have broken links, we will provide you with a report of the broken links. These links will need to be either fixed or removed before the site can be approved for launch.
    • Must adhere to University branding guidelines.
    • Cannot use in-line styles or use text/image formatting inconsistent with the approved BU WordPress themes.
    • Must meet BU’s Minimum Web Accessibility Standards. Please learn how to implement these 10 accessibility best practices in your site to remain compliant with accessibility requirements.

Virtual Hosts

If your website uses a virtual host address (for example: mysite.bu.edu, rather than the standard www.bu.edu/mysite/) you may need to provide IS&T up to two weeks advanced notice before we can launch your site. Virtual host configuration changes are only performed during off-hour change windows and require testing before they are scheduled and deployed.