Websites/Taskforce/Proposals/Domain Name Strategy

From MozillaWiki
Jump to: navigation, search

Domain Name Strategy

If you have any questions about how this document applies to any work you are doing or if you have feedback or comments or need clarification, please contact david at mozillafoundation dot org and jslater at mozilla dot com.

This strategy applies only to websites and does not intend to cover anything to do with email addresses.

Working Group

John Slater, Janet Swisher, Laura Forrest and David Boswell

Status

This proposal was approved at the 10/21/10 task force meeting.

Problem

We are currently using our organizational structure as a way to set up domain names and this is presenting irrelevant information to people and diverting our message away from more important things, such as what we do and why we do it.

For example, the following are some of the organizational domains currently in use:

  • mozilla.com
  • mozillamessaging.com
  • mozilla-europe.org*
  • mozillaonline.com*
  • mozilla.jp*

Note that mozilla.org is not an organizational domain -- it is the community's domain that was set up and used long before there was any Mozilla organization. It isn't the Foundation's organizational domain -- that is mozillafoundation.org that was in use briefly but has been retired.

*Affiliate URLs act as both an organization site and a local site, so there is no need to move away from using those domains. The more important issue with affiliate sites is making the content as relevant as possible by de-emphasizing the organizational information and highlighting the locale specific information.

Solution

To be able to stop using organizations as a basis for our domain name strategy, we need to develop an alternative that uses something else for its structure. There seem to be two main options:

  • Structure a strategy based on product/activity: firefox.com, thunderbird.com, drumbeat.org, etc.
  • Structure a strategy based on everything being a part of Mozilla: www.mozilla.org, addons.mozilla.org, foo.mozilla.org

Both options have advantages and disadvantages, but they are mutually exclusive so we need to pick one (although we can certainly maintain redirects for any URLs we want).

"One Mozilla" Strategy

To create a "One Mozilla" strategy for domain names, we propose using sub-domains for functional areas and sub-directories for products and programs (programs in the initiative sense) with some exceptions. So:

  • service.mozilla.org/sub-category

The following breaks out how this general rule applies to different types of sites.

Product and Program Sites

Sites related to the major activities backed by Mozilla organizations should use sub-directories on www.mozilla.org. The service being offered here is delivery of web pages (compared with delivery of a web app providing specific functionality).

Examples:

  • www.mozilla.org/firefox
  • www.mozilla.org/thunderbird
  • www.mozilla.org/drumbeat

Note: Other community-backed projects such as seamonkey-project.org can show affiliation with Mozilla on their site in a number of other ways without having to change their URL structure.

Web Application Sites

Sites that exist to host services should have sub-domains based on the service offered and sub-directories based on products or programs. This is the existing addons.mozilla.org model.

Examples:

  • addons.mozilla.org/firefox, addons.mozilla.org/mobile, addons.mozilla.org/thunderbird, etc.
  • support.mozilla.org/firefox, support.mozilla.org/mobile, support.mozilla.org/thunderbird, etc.
  • nightly.mozilla.org/firefox, nightly.mozilla.org/mobile, nightly.mozilla.org/thunderbird, etc.

For sites that provide a service for the community as a whole and not for specific programs or products, there is no need to divide things by sub-directory.

Examples:

  • air.mozilla.org
  • developer.mozilla.org
  • feeds.mozilla.org

Campaign Sites

Mini-sites set up for a specific campaign should be able to use whatever URL makes sense. Because these sites are usually relevant to a specific time, an archiving plan should be put in place so this content isn't abandoned.

Examples:

  • firefoxflicks.com
  • opentochoice.org
  • operationfirefox.com

Local Sites

There are two main URL styles being used today by local sites.

Examples:

  • mozilla.country: mozilla.jp, mozilla.ro, etc.
  • mozilla-country.org: mozilla-mexico.org, mozilla-russia.org, etc.

There are also a variety of other URLs in use such as bgzilla.org and mozilla.org.ua. It may make sense to make these more consistent, but there is no plan to do that now. On the other hand, having flexibility with local site URLs allows us to deal with issues relevant to different locales.

Mobile Sites

Ideally each site would have one URL which would present its content in a form optimized for any device. For complex sites though, the functionality available on mobile versions may differ greatly and switching style sheets alone may not be sufficient.

When it isn't possible to maintain a single URL for a site, we recommend adding a "m." at the beginning of the domain, such as

  • m.foo.mozilla.org.

In the cases when we do choose to go with separate mobile URLs, once we take the time to do things the ideal way we can just redirect mobile URLs to their desktop equivalents for a seamless transition.

Other Sites

Mozilla is a big community with many people doing many things and there's no benefit to making every site fit in some structure. It is fine for some sites to have unique URLs as long as they avoid organization specific domains or trademark violations.

Examples of sites with unique URLs that are fine:

  • accessfirefox.org
  • geckozone.org
  • mozillamemory.org

Proposed URL Changes

Using the principles of the "One Mozilla" strategy, we suggest the following URL changes (this is just an initial batch and not comprehensive of all possible URL changes).

Existing URL Proposed URL Comment
mozilla.com www.mozilla.org/firefox
mozillamessaging.com www.mozilla.org/thunderbird
support.mozilla.com support.mozilla.org
mobile.support.mozilla.com support.mozilla.org/mobile
support.mozillamessaging.com support.mozilla.org/thunderbird
air.mozilla.com air.mozilla.org
feeds.mozilla.com feeds.mozilla.org
input.mozilla.com input.mozilla.org

Technical Considerations

Localization

The best practices around how to use locale codes in URLs shouldn't need to be changed due to this proposal. Sites can still use the following scheme (with the example here of Mozilla Europe's German Firefox page):

  • www.mozilla-europe.org/de/firefox/

The bigger issue with the l10n process is how will this proposal change how localizers determine what to work on? If sites are aggregated into fewer domains will more content need to be localized or would we create less cohesive experiences with partially localized sites?

Security

Moving from multiple unique domains to subdomains of a single domain, and in some cases subdirectories within that subdomain, will require changes to the security requirements that are imposed upon these websites. Specifically, all websites that are grouped within the same subdomain will be subject to the highest security requirements of any site within that subdomain.

In some cases this may mean that a site that was previously not hosting or performing critical operations, and thus had more lenient security controls, would be required to significantly enhance the security controls before it could be added as a subdirectory of a more security restrictive subdomain.

In addition, depending upon the criticality of a given group of websites within a subdomain this may result in a more strictly controlled security review process including requirements to review any new code before it is pushed live to the site.

Webtrends Tracking

From Webtrends - You should be fine changing over from the .com domain to the .org domain, as long as the primary domain designated in the Webtrends JavaScript tag points to what you consider the primary domain. Additionally, if you plan on having both domains concurrently available, you may want to modify the JavaScript tag to include mozilla.com at a value for the this.onsitedoms=""; entry in the JavaScript include. This would then consider all traffic from mozilla.com to be considered part of the traffic on the primary domain and would not prefix entries in reports with "Offsite:"

SEO Best Practices

SEO Best Practices When Switching Domains

Please take the following into consideration when making these switches to minimize any possible dips in natural search traffic.

Redirect Treatment (Technical Owner)

  • The most important thing to avoid is 404 (file not found) errors when searchers click on Mozilla site links that show up on the search engine response page (SERP)
  • Use a permanent 301 redirect to redirect the pages on the old site to the new site. This also lets Google know all the pages have officially moved.
  • Change all internal site links to point to the correct domain
  • Use link checking software to find any broken links
  • Submit a new sitemap to Google Webmaster Tools and Yahoo Site Submit
  • Do this in phases if possible, moving one subdirectory over at a time, monitoring the results

Incoming Links (Business Owner)

  • If possible, contact the main owners of our largest incoming traffic and have them change the link (Google Snippets, YouTube, Affiliate Programs, and many more)
  • Closely monitor SERP results and incoming organic search traffic for major changes


References http://googlewebmastercentral.blogspot.com/2008/04/best-practices-when-moving-your-site.html http://www.clickz.com/clickz/column/1699947/seo-best-practices-when-moving-web-site http://www.seomoz.org/blog/seo-guide-how-to-properly-move-domains

Also a recent quote from Matt Cutts of Google: 

When done correctly, a 301 redirect shouldn't cause any drop in traffic, says Matt Cutts, a Google software engineer. He says instead of moving its entire website at once, Evo would have been better off moving the site very slowly, starting with the least-trafficked areas of its website. Changing something like the structure of a site during a move can also cause problems. "If someone changes to a new template, that can affect the rankings," says Cutts. "Sometimes it takes Google a little while to figure out how best to process, index, and rank a page."

And input from Rand Fishkin of SEOmoz on our particular case:

On the switch over - I suspect it will be relatively painless, but you might want to do as Google recommends and switch part of the content first, then move over in batches, rather than all at once. You can see Matt Cutts discussing this in an Inc article recently...It's not critical, IMO, but it might save some pain in that "Google's figuring things out" timeframe.



Product Links

The following is quoted from bug 606278 as part of a discussion about issues involving switching domains for sites that are linked to from within our products:

Same thing goes for byob.mozilla.com, as I mentioned in bug 607129. Not so much that it's coded into Fx4, but that the domain name is part of the configuration distributed with custom browsers.

FWIW, this is not something I see mentioned in the strategy: Existing sites are linked to by other sites and coded into products / configurations in the wild (ie. outside our control). Cleanly moving things may not be possible in all cases, so we'll need some consideration around transitions.

Some sites may need to be served up at both the new and old locations, if only with a 301 redirect at the legacy URL. However, some URLs may not be amenable to redirects - ie. sites offering APIs like addons.mozilla.org

It's also possible that there may be some URL namespace collisions where old/new URLs need to co-exist for an extended period of time. I can't think of any off the top of my head, though

Implementation

Once we've agreed on the plan we want to roll out these changes incrementally. Doing everything at once would be too big a project and we expect there will be things to learn about the process as we start making changes.

To follow along with the progress of things, see bug 606278

mozilla.com domains to switch

The following is the list of mozilla.com domains to switch and the associated bugs.

  • brasstacks.mozilla.com
  • etherpad.mozilla.com
  • identity.mozilla.com
  • metrics.mozilla.com
  • services.mozilla.com
  • status.mozilla.com

mozillalabs.com domains to switch

The plan here is for Labs to switch over to mozillalabs.org. They will implement and we can check in as needed.

  • apps.mozillalabs.com
  • design-challenge.mozillalabs.com
  • jetpack.mozillalabs.com
  • gaming.mozillalabs.com
  • bespin.mozillalabs.com
  • builder.mozillalabs.com
  • heatmap.mozillalabs.com
  • prism.mozillalabs.com
  • testpilot.mozillalabs.com
  • www.mozillalabs.com

mozillamessaging.com domains to switch

Mozilla Messaging will switch the domains and we can help as needed.

  • f1.mozillamessaging.com
  • ispdb.mozillamessaging.com
  • support.mozillamessaging.com
Retrieved from "https://wiki.mozilla.org/index.php?title=Websites/Taskforce/Proposals/Domain_Name_Strategy&oldid=759754"