Why Split the Site
Learning Website: Framework & Architecture
Chapter 1 · Why Split the Site
This learning site began as a handful of pages and has grown into a very large collection of courses,
lessons, cheat sheets and tools. Growth is the point, but a single site that holds everything has costs
that grow with it: longer builds, a bigger navigation to understand, and one deployment that every change
has to pass through. This course is a blueprint for rebuilding the site as a family of smaller sites, such
as languages.osztromok.com and webdevelopment.osztromok.com, with
osztromok.com itself eventually becoming a portfolio and landing page. This first chapter asks
whether that is worth doing, and gives you a way to decide.
What Hurts on One Big Site
Before choosing a solution, list the actual problems. These are the ones a single large content site tends to meet:
| Problem | What you notice |
|---|---|
| Build time | A static site generator builds every page on every deploy, so the build grows with the page count. A small change to one chapter costs a full rebuild. |
| Navigation overload | Menus have to list every subject, so a visitor looking for one language course sees dozens of unrelated ones. |
| One deployment for everything | A mistake in one area can break the whole site, and a fix for one area waits behind unrelated work. |
| Different needs per area | The language courses have their own colours, dialog blocks and audience. A programming course needs code blocks and runnable examples. One shared layout serves neither well. |
| Unmanageable content tree | The folder structure grows deeper and wider, and rules for each content type pile up in one place. |
Count these for your own site before you decide. Exercise 1 at the end of the chapter shows how to measure how many pages each area holds, which tells you whether the problem is real.
What a Subdomain Is
A subdomain is a name added in front of your domain: languages in
languages.osztromok.com. It is set up in DNS, and it can point at a different folder, a
different application or even a different server from the main site. A path is the part
after the host name: /languages/ in osztromok.com/languages/. A path always lives
inside one site.
All three names above point at the same machine. The web server (Apache or Nginx, covered in Learning Website: Framework & Architecture 8) looks at the host name in each request and decides which site to serve. So a subdomain split does not need more servers; it needs more configuration.
What a Subdomain Split Gives You
- Independent builds and deploys. The languages site rebuilds only when language content changes. A failed deploy of one site leaves the others alone.
- A smaller, focused site. Navigation, search and layout only describe one area, so a visitor sees what is relevant to them.
- Area-specific design. Each site can have its own accent colour, components and rules, while still sharing a common base (Learning Website: Framework & Architecture 4).
- Room to choose technology per site. The languages site could be built differently from a future site that needs a database or user accounts.
- A clear public structure.
osztromok.comcan become a short portfolio page that links out to each area.
What It Costs
The costs are real, and most of them come from one fact: a subdomain is a different origin.
Origins and sites
A browser treats two URLs as the same origin only when the scheme, host and port all match.
languages.osztromok.com and osztromok.com have different hosts, so they are
different origins, although they are still the same site because they share the registrable
domain osztromok.com. Exercise 3 turns this into a small script you can run.
| Feature | Path split (one origin) | Subdomain split (several origins, one site) |
|---|---|---|
| localStorage and sessionStorage | Shared by every page | Separate for each subdomain |
| Cookies | Shared | Shared only if set with a Domain attribute for the parent domain |
| fetch() from one area to another | Allowed | Blocked unless the other site sends CORS headers |
| Shared fonts and assets | Simple | Cross-origin fonts need CORS headers; a shared asset host is often easier |
| Links between areas | Relative paths | Absolute URLs, kept in one configuration file |
osztromok.com with the Domain attribute is sent to every
subdomain, which is convenient and also widens the damage if one subdomain is compromised. This is why the
optional accounts chapter (Learning Website: Framework & Architecture 9) is kept separate: decide whether
you need shared accounts at all before you build the sites.
Certificates and setup
Every hostname needs to be covered by an HTTPS certificate. You can get one certificate per subdomain, or one
wildcard certificate for *.osztromok.com. A wildcard covers a single label
only, so languages.osztromok.com is covered but a.languages.osztromok.com is not.
With Let's Encrypt a wildcard certificate has to be requested using DNS validation, which means automating
changes to your DNS records. You also add a virtual host to the web server for each site.
Search and discoverability
Search engines can index subdomains, and Google has said it can handle either subdomains or paths. The practical differences are smaller than the folklore suggests, but they are real: each subdomain is crawled and reported separately, you have more places to keep sitemaps and redirects correct, and any search ranking the old combined site earned has to be carried over carefully when you move content (Learning Website: Framework & Architecture 7 and 11). A “domain” property in Google Search Console covers every subdomain, so you can still see the whole picture in one place.
Duplicated effort
Anything shared now has to be shared on purpose: the top navigation, the footer, the colour scheme, the code-copy script, the sitemap logic. A split without a shared design package turns into several slightly different copies of the same site, which is worse than the single site you started with.
Subdomain or Path?
There is a middle option, and for many sites it is the right one: keep one domain and one origin, but split
the content and the build. The area still appears at osztromok.com/languages/, while the web
server or a small proxy sends that path to a separate, independently built site. You get independent builds
and deploys without any of the origin-related costs above.
A path split is simpler to run. A subdomain split gives more independence and a clearer identity for each area. This course assumes subdomains because that is the direction you have chosen, but every design in it (the shared content model, the design package, the configuration of links) works for a path split as well, so the decision can be revisited.
A Way to Decide
Score each area, not the whole site. An area is a good candidate for its own site when most of these are true:
| Signal | Points towards |
|---|---|
| It is large, or growing fast | Its own site (build time, navigation) |
| Its audience differs from the rest | Its own site (separate identity) |
| It has its own design rules | Its own site with a shared base |
| It needs different technology | Its own site |
| Visitors move often between it and other areas | A path split, or keep it together |
| It needs login shared with other areas | A path split, or a deliberate shared-login design |
| It is small and stable | Keep it where it is |
Staying Honest About the Cost
Whatever you decide, plan to keep the old site running while the new one grows. You will not move everything in one weekend, and you should not have to. Moving one area at a time means each step is small, can be tested, and can be undone. Learning Website: Framework & Architecture 10 describes this approach, usually called the strangler pattern, in detail.
Hands-On Exercises
Measure your site. Count the HTML files under each top-level folder of content/, rank the areas by size, and write down which areas are big, which are growing fastest, and which would still need many links to each other after a split.
Write a one-page decision record for the languages area. State the context, the two options (path or subdomain), at least six criteria with scores, your decision, and its consequences. Say which criteria you weighted most and why.
📄 View solutionWrite a short Python script that takes two URLs and reports whether they are same-origin, same-site but cross-origin, or cross-site. Test it on a path pair, two subdomains, an http/https pair and a different port. Explain what each result means for cookies and localStorage.
📄 View solutionChapter 1 Quick Reference
- Reasons to split: build time, navigation overload, one deployment for everything, different needs per area
- Subdomain = a name in DNS (
languages.osztromok.com); path = part of a URL inside one site (/languages/) - Origin = scheme + host + port; site = scheme + registrable domain
- A subdomain split makes several origins within one site: localStorage is separate, cookies are shared only with a parent
Domain, and fetch needs CORS - A wildcard certificate (
*.osztromok.com) covers one label only, and Let's Encrypt needs DNS validation to issue one - A path split can give independent builds without the origin costs
- Score each area (size, growth, audience, design, technology, cross-links, shared login), not the whole site
- Keep the old site running and migrate one area at a time