When first getting started with a new space on a Web host, it may be helpful to imagine having access to a small “territory” of the Web. Everything placed in a public folder on within this territory becomes available for anyone on the Web to see, assuming they know how to find it.
If a project is just a handful of static HTML pages which need to be available to colleagues or friends, then working within a single somewhat unorganized space may work just fine. But as soon as a project grows to the point where it requires more organization, a new strategy is required.
Consider this scenario: a Bergbuilds user wants to have a personal blog within her Web territory to share pictures and writings with colleagues and family back home. In addition, she's working on a large research project that requires a Web-based repository of digital images. She wants to use one application (WordPress) to manage the personal blog. For her research project, she settled on another open-source application (Omeka). Both are applications that need to be installed on her Bergbuilds Web host, but she can’t just put them both at the 'base' of her Bergbuilds domain. If she did, both sites would likely experience conflicts and errors. Instead, she needs to cordon off separate territorial spaces for her different Web “properties”.
There are two primary strategies for parceling up a Bergbuilds Web space. One strategy is to create various subdomains (technically sub-subdomains). The other strategy is to create various subdirectories. To understand the difference, it's helpful to understand what is meant when we talk about a root domain.
Imagine for a moment working with a privage Web hosting company, and not through Bergbuilds. A user has registered a new domain called yourdomain.com. Anything that is stored at this base URL is considered to be at the "root" of that domain: nothing comes before the address or after the address. In many cases, users decide to simply have a single site on their Web host (maybe a blog running WordPress), and they set that blog up at their domain’s root. To get to the Wordpress blog in this scenario, visitors would simply type http://yourdomain.com into a browser.
When folks want to do more than have a single site, they need to decide how to organize this file space. After all, Web servers primarily serve files to a browser that requests them. One successful strategy for keeping contents organized and accessible to people who need them is to set up subdomains. Subdomains are as much about sparing the reader's effort as they are helping the site owner stay organized. For instance, it is much easier for a potential blog reader to remember: http://blog.kermit.bergbuilds.domains than it is to remember http://kermit.bergbuilds.domains/this_is_the_first_page_of_my_blog.html. Organizing sub-sites with subdomains helps assist memory, helps visitors know 'where' they are within a site. Subdomains also help content owners stay organized, and subdomains help everyone type less!
While working at Bergbuilds.domains, users are welcome to create as many subdomains as they need. Each subdomain can contain create a distinct Web site (or Web application), a directory of documents, or a portfolio. A Bergbuilds user may think one item (for instance, a resume) is so important as to warrant its own subdomain (for example, http://resume.kermit.bergbuilds.domains). Subdomains might be a great way to serialize Web projects (for example, http://roadtrip2016.kermit.bergbuilds.domains). It may be helpful to think of subdomains as providing a kind of organization at the "front" of a Bergbuilds URL.
The alternative for organizing Bergbuilds territorial space is to set up subdirectories. These function much like file folders on a computer hard drive. Instead of creating a blog at http://blog.kermit.bergbuilds.domains a user would place the blog Web application within a subdirectory called “blog” making the address http://kermit.bergbuilds.domains/blog. Setting up one or many subdirectories is really easy. The File Manager within the cPanel allows for directory and subdirectory creation. Also, many Web applications permit their automatic creation during installation via Installatron.
Use of subdomains may seem to be a cleaner, more elegant solution to organizing a Bergbuilds domain. Use of subdomains to install multiple Web applications is less likely to present conflicts or errors. However, relying upon subdomains as opposed to subdirectories requires a little more preparation. Subdomains must be created first, and Web applications are then installed afterward into them. Use of subdirectories may result in longer URLs than subdomains, but they’re easier to set up - often a subdirectory can be created automatically by the Installatron at the point of installing a Web application.