Subdomains or subfolders? How I reorganised a dozen sites

For years I gave every project its own subdomain: quiz.portale3d.it, varco.portale3d.it, intercity.portale3d.it and so on. It is the most natural choice when a project is born: new folder, new address, no conflict with anything else. Then one day the hosting panel told me I had run out of subdomain slots. I had to decide: buy a bigger plan or change the structure.

I changed the structure. In this guide I walk you through the reasoning and the practical steps, so you can apply them to your own sites.

The dilemma in short

The two options are:

• subdomains: project.mysite.com, each one treated almost as a separate site;
• subfolders: mysite.com/project/, everything under the same domain.

Technically both work. The difference lies in three areas: how Google sees them, how you handle user logins and how much they cost you to maintain.

SEO: what really changes

Google has said many times that it handles both subdomains and subfolders well. In practice, though, a subdomain is often treated as a separate property: links pointing to quiz.mysite.com help the main domain less, and vice versa.

For a personal site with many small projects this matters. None of my games had enough links to stand on its own; grouped under a single domain, they strengthen each other.

Before deciding I looked at the real data: visit statistics and Google Search Console. Organic traffic to the old subdomains was close to zero. That allowed me not to worry about redirects from every old address: updating the internal links and setting the right canonical URL on each page was enough.

Before you reorganise, check the data. If an old address gets traffic from Google or from external links, it needs a 301 redirect. If it doesn't, you can save yourself the effort.

The structure I chose

I split everything into three groups, by type of content:

Games are the only exception: they keep a subdomain, but just one for all of them. They have different needs (separate sessions, shared leaderboards, more permissive security headers for iframes), and having them all under one address still makes them a coherent site.

One login for everything

The most concrete advantage of subfolders isn't SEO: it's the login. With one subdomain per project, each one had its own sign-in system, its own user table, its own cookie. Under the same domain, a session cookie works for every folder.

I wrote a small shared library that does three things: starts the session, reads the user from a central table and shows the same menu everywhere. Each app includes it with one line:

require_once $_SERVER['DOCUMENT_ROOT'] . '/core/auth.php';
$user = p3d_user();   // signed-in user or null

I didn't rewrite the old apps. Each one checks whether the shared library exists: if it does, it uses it; otherwise it carries on with its previous login. That made the transition gradual, one project at a time.

Be careful, though: same origin also means same risks. If all apps live on mysite.com, a vulnerability in one can affect the others. That's why the rules get stricter: HttpOnly and Secure cookies, CSRF tokens on forms, no access tokens in localStorage, and localStorage keys always prefixed per app.

Moving without copying: symbolic links

Many apps lived in folders outside the main site, with their own configuration. Moving them physically meant risking broken paths and permissions. On shared hosting that supports them, the answer is a symbolic link: the folder stays where it is and the main site "sees" it at a new address.

One detail worth knowing: inside the app, PHP's __DIR__ returns the real path, not the link's. If the app needs files from the main site, it has to go through the site root ($_SERVER['DOCUMENT_ROOT']) rather than paths relative to its own folder.

The hidden enemy: absolute paths

An app born on a subdomain assumes it lives at the root. Throughout the code you find things like /assets/style.css or fetch('/api/save.php'). Moved into a subfolder like /varco/, that leading slash points to the root of the domain, which is the wrong place.

When I migrated the card game Varco I found more than ninety references like that, spread across PHP pages, JavaScript and CSS. And not only in the code: in the database too, where every card had its image path stored with the leading slash.

The rule that works: relative paths everywhere. Drop the leading slash and let the browser resolve the address against the page. In CSS, remember that paths are relative to the .css file, not to the page. Before touching data in the database, always back up the table.

The checklist I would use again

1. Look at the traffic data and decide which old addresses deserve a redirect.
2. Define the folder structure before moving anything.
3. Build the shared library (login, menu) and merge it on its own, before the apps.
4. Migrate one project at a time and check it in the browser: pages, API calls, images, a console without errors.
5. Search for absolute paths in the code and in the database.
6. Update every page's canonical URL and the internal links.
7. Remove the old subdomains only once the new address has worked for a few days.

Wrapping up

Subfolders aren't magic, but for a personal site with many small projects they won across the board: one domain to grow, one login to maintain, one menu linking everything together. And in the end, running out of space on the hosting was the opportunity to tidy up.

Published on October 7, 2026.