The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →A subdomain shares your main site’s database only when the application is deliberately connected to the same database service and its data boundaries are designed. DNS merely sends sub.example.com to a server; it does not create a database connection, share WordPress content, or make logins work automatically.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
For a WordPress site, the cleanest option is usually WordPress Multisite: one WordPress installation, one database, separate tables for each site’s content, and a shared user table. A separately deployed application can also use the same database, but it needs explicit table prefixes or tenant keys, permissions, migrations, backups, and authorization rules. The steps below show how to choose and implement the right model without accidentally exposing data.
As an Amazon Associate I earn from qualifying purchases.
What “sharing the database” actually means
A database is a service containing schemas, tables, users, and records. A subdomain is only a hostname. When someone visits sub.example.com, DNS resolves that hostname, a web server selects an application, and the application decides which database connection and records to use.
There are three different kinds of sharing, and they should not be confused:
#1 Best Overall
- Used Book in Good Condition
- Shared authentication: users can sign in on the main site and be recognized on the subdomain.
- Shared business data: both applications can read or update the same customers, orders, projects, or other records.
- Shared CMS content: posts, pages, settings, media, and taxonomies are intentionally available across sites.
One database can provide one, two, or all three. Conversely, two sites can use the same database server while keeping their tables and permissions completely separate. Decide the sharing boundary before creating DNS records or changing application settings.
Choose an architecture before you configure DNS
| Approach | Installation and files | Database isolation | Users and sessions | Content sharing | Deployment independence | Main operational risk |
|---|---|---|---|---|---|---|
| WordPress Multisite, subdomain network | One WordPress installation and one database | Each site receives its own content tables; the user table is shared | Shared users are built in; cross-site capabilities still need configuration | Not shared by default; code must deliberately exchange content | Network-wide core and plugin changes; less independent than separate installs | A network-wide mistake can affect every site |
| Separate WordPress installations, one database | Independent files and deployments | Use a distinct table prefix for every installation, such as main_, projects_, or test_ |
Separate by default; shared login requires an intentional integration | Separate unless applications query one another’s tables | High; each site can be upgraded and rolled back independently | Prefix collisions, migrations, backups, and excessive database privileges |
| One custom application serving several hosts | One codebase and deployment | Use a site or tenant key in every tenant-owned table and query | Can be shared centrally; cookie and origin policy must be designed | Whatever the application model permits | Usually one deployment pipeline | A missing tenant filter can disclose another site’s records |
| Separate frontend on a subdomain | Independent frontend calling the main application through an API | The API owns database access | Requires credentialed cross-origin requests and correctly scoped cookies or tokens | Controlled by API endpoints, not by DNS | High for the frontend; API remains shared | CORS, cookie, CSRF, and authorization errors |
WordPress documents the Multisite model as a single WordPress instance with a single database. Its sites have unique content tables, while the user table is shared. Network sites do not automatically share one undifferentiated set of posts and settings. A separate-installation design can point multiple WordPress instances at one database, but only when each instance owns a distinct table prefix and the database permissions are carefully limited.
When WordPress Multisite is the right choice
Use a subdomain-based Multisite network when the subdomain is another site in the same WordPress organization: for example, docs.example.com, events.example.com, or a regional site managed by the same administrators. You get one core installation, one database, centralized user identities, and per-site content tables.
What Multisite shares
- The WordPress user table is shared across the network.
- Network administrators can manage installations, themes, plugins, and updates centrally.
- Each site has its own posts, pages, options, and related tables.
What Multisite does not share automatically
- A post created on one site does not appear on another site by default.
- Site-specific options, menus, widgets, and media relationships remain associated with their site.
- Being a network user does not automatically grant administrator privileges on every site.
If the requirement is “one login, but separate site content,” Multisite matches the requirement. If the requirement is “both hostnames must edit the exact same post tables,” that is a different integration and should not be implied by the word Multisite.
When separate applications should share one database
Separate deployments are appropriate when the subdomain has its own release cycle, framework, language, or security boundary. For example, a main WordPress site could coexist with a separately deployed project portal. The applications may use the same database endpoint, but they should not casually operate on each other’s tables.
Separate WordPress instances
Assign a unique table prefix during each installation. A main site might own main_ tables and a project site might own projects_ tables. Every migration, backup, restore, and maintenance script must preserve that ownership. Never reuse a prefix in a database that already contains another installation.
Recommended Free Tools
Custom applications
Put a tenant or site identifier on every row that belongs to a specific host. Resolve the incoming hostname to a trusted site record, then include that site key in every read, update, delete, report, cache key, and background job. Authorization must be enforced server-side; hiding another tenant’s records in the user interface is not isolation.
Prefer a database account with only the privileges that application needs. If the project application does not need to modify billing tables, do not grant it write access to them. Separate credentials also make it possible to revoke one application without taking the entire network offline.
Rank #3
Implementation sequence: DNS to database
Complete these stages in order. A successful DNS lookup does not prove that the application, TLS certificate, session policy, or database isolation is correct.
- Write the sharing contract. List whether you need shared users, shared sessions, shared business records, shared CMS content, or merely a common database server. Name which application owns each table or schema and which operations are permitted.
- Create the hostname in DNS. Add an address record for
sub.example.comthat points to the same load balancer or server as the main site. If many tenant hosts must reach one application, use a wildcard record such as*.example.com, subject to your DNS provider’s syntax and certificate support. A wildcard does not replace application-level host validation. - Route the host at the web server or platform. Add the hostname to the correct virtual host, container, ingress rule, or hosting control panel. Ensure requests are forwarded to the intended application and that URL rewriting preserves the original host. WordPress’s wildcard setup routes those hostnames to the same installation folder, but the web server still has to recognize them.
- Register the host in the application. In Multisite, create the site in the network administration area and choose the subdomain address. In a custom application, map the hostname to a site or tenant record and reject unknown hosts. In a separate frontend, configure the API base URL and allowed origin explicitly.
- Provision HTTPS for every hostname. Issue a certificate covering the main domain and each required subdomain, or a wildcard certificate where appropriate. Test the HTTPS endpoint directly and confirm that HTTP redirects to the intended HTTPS URL without changing the host unexpectedly.
- Point applications at the database service. Use the same database host, port, database name, or cluster only when that is the intended design. Keep credentials in protected environment or secret-management settings rather than source code. For separate WordPress installs, set a unique table prefix before installation; for tenant applications, ensure the site key is available before any query runs.
- Configure migrations and backups. Record table ownership, migration order, restore dependencies, and which application must be stopped during schema changes. A backup that restores the database but not the matching application configuration can leave hosts pointing at the wrong tables.
- Configure sessions only if required. Keep host-only cookies when independent logins are acceptable. If a session must work across subdomains, use a parent-domain cookie only after assessing the trust relationship between every subdomain. Configure credentialed CORS for browser requests and align the cookie’s Domain, Secure, HttpOnly, and SameSite attributes with the intended flow.
- Test in staging before production. Test normal requests, unknown hosts, expired sessions, failed API calls, redirects, TLS, database errors, backups, and rollback. Use two test users and two test tenants to prove that changing the host or an identifier cannot reveal the other tenant’s records.
WordPress Multisite setup considerations
Before enabling the network
- Confirm that your hosting stack supports WordPress Multisite and subdomain routing.
- Take a full database and file backup, including uploads and configuration.
- Decide whether existing content remains the main site and whether new sites use subdomains or another network mode.
- Make sure the DNS and TLS plan covers every site you intend to create.
Creating a subdomain site
- Enable the Multisite feature in the existing WordPress installation according to the version-specific WordPress administration instructions.
- Choose the subdomain network type and complete the network setup shown by WordPress.
- Apply the generated configuration changes to the WordPress configuration and rewrite rules exactly as displayed for your installation.
- Open the network dashboard, choose the site-management screen, and add the new site with its subdomain address, title, and administrator email.
- Sign in to the new site, verify its URL and permalink behavior, and create a test page. Confirm that the page appears only in that site’s content area.
Changing an existing network from one address pattern to another is more than a rewrite-rule edit. Stored site addresses, DNS, virtual hosts, TLS certificates, redirects, and cookies must agree. Plan the change as a migration and test old and new URLs before switching traffic.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsSharing login across subdomains
A shared database user table is not the same as a browser session shared across hosts. The browser decides whether to send a cookie based on its Domain, Path, Secure, SameSite, and HttpOnly attributes, while the server decides whether that session is authorized for the requested site.
Same application or Multisite
When the same WordPress network or application handles both hosts, centralized users can work with less integration. You still need to assign the user the correct site role and verify that redirects return to an allowed hostname.
Separate frontend and API
A frontend at one subdomain calling an API at another is a cross-origin request even though both names share a parent domain. The API must return an explicit allowed origin, permit credentials when cookie sessions are used, and implement CSRF protection appropriate to that session design. Wildcard origins are not a substitute for a specific, trusted origin when credentials are sent.
Framework guidance for Laravel Sanctum identifies misconfigured CORS or session-cookie settings as common causes of authentication failure for a single-page application on a separate subdomain. The session cookie’s parent-domain scope must cover the hosts that need it, and the browser request must opt into credentials.
Security boundary of a parent-domain cookie
A cookie scoped to .example.com is available to the included subdomains. Django’s session documentation warns that a subdomain under an attacker’s control can set or influence cookies for the parent domain, allowing it to attack the broader session scope. Treat every subdomain that receives or can set a parent-domain cookie as part of one trust boundary. Do not use a shared parent-domain session when unrelated teams, untrusted code, or weaker security controls exist on another subdomain.
Database isolation and authorization rules
For table-prefix isolation
- Reserve a prefix for each application and document it.
- Give each application only the database privileges it needs.
- Make migration tools assert the expected prefix before changing tables.
- Back up and restore prefixes as a unit, and test restores on a non-production database.
For tenant-key isolation
- Resolve the host to a tenant record from a trusted configuration table.
- Load the tenant context before controllers, jobs, exports, and command-line tasks query data.
- Require the tenant key in every query, including administrative searches and background processing.
- Check object ownership again on updates and deletes; never rely on an ID alone.
- Include the tenant in cache keys, file paths, event payloads, and audit logs.
Shared tables for genuinely global records can be useful, but document whether a record is global or tenant-owned. Ambiguous ownership is a frequent cause of accidental cross-site access.
Common failure modes and fixes
The subdomain shows the main site or a default page
Check DNS resolution, the virtual-host or ingress rule, and the application’s host mapping in that order. A wildcard DNS record can send traffic to the server while the web server still routes the request to the wrong application. Confirm the host header reaches the application and that the subdomain is registered as a valid site or tenant.
WordPress returns a redirect loop or “not found” page
Verify that the stored site URL, network URL, rewrite rules, HTTPS redirect, and proxy scheme agree. Mixed HTTP and HTTPS assumptions often create loops. Re-save the relevant permalink or network settings only after taking a backup, and test from a clean browser session to avoid stale cookies.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteLogin works on one host but not the other
Inspect the browser’s cookie attributes. A host-only cookie will not be sent to the sibling subdomain; a parent-domain cookie may be rejected because Secure, SameSite, or domain settings do not match the request. For an API architecture, check the exact allowed origin and whether both the browser request and server response permit credentials. Also verify that the post-login redirect points to an approved host.
Users exist but cannot see the expected content
In Multisite, the user table is shared but site membership and roles are site-specific. Add the user to the intended site and confirm that the application is querying that site’s tables. Do not assume that a shared login means shared posts.
One application can read another application’s records
Review database grants first, then inspect application queries for missing table prefixes or tenant filters. Add automated tests that attempt to access a second tenant by changing the host, record ID, or API parameter. A UI-level restriction is insufficient if the underlying endpoint still accepts an unauthorized identifier.
Wildcard hosts work inconsistently
Check that the wildcard DNS record, certificate, web-server rule, and application host resolver all support the same hostname pattern. Explicitly reserve administrative, mail, and other special subdomains so they cannot be interpreted as tenant names accidentally.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Testing checklist before launch
- Each intended hostname resolves to the correct endpoint over HTTPS.
- Unknown or misspelled hosts are rejected or redirected safely.
- The certificate is valid for the main site and every required subdomain.
- Each host loads the intended site or tenant, not a default or neighboring one.
- A user with access to site A cannot read or modify site B by changing a URL, host, ID, or API parameter.
- Cookies show the planned Domain, Path, SameSite, Secure, and HttpOnly attributes.
- Cross-origin API calls succeed only from approved origins and fail without valid credentials.
- Login, logout, password reset, and redirect flows work from every supported host.
- Backups include database tables, uploads, configuration, DNS records, and certificate renewal arrangements.
- A restore test proves that table prefixes, tenant mappings, and application versions remain compatible.
- Network-wide updates and independent deployments each have a tested rollback path.
How to decide between the options
Choose WordPress Multisite when
- All sites are WordPress and managed by one organization.
- You want one user directory and centralized administration.
- Per-site content tables are acceptable and content can be exchanged through deliberate code or editorial workflows.
- Network-wide updates are preferable to completely independent releases.
Choose separate installations with one database when
- Each WordPress site needs independent files, plugins, deployment timing, or rollback.
- You can enforce unique table prefixes and maintain clear schema ownership.
- Separate users and sessions are acceptable, or you are prepared to build a secure identity integration.
Choose a tenant-aware application when
- The subdomain is simply another host for the same product.
- Business records must be shared through one controlled domain model.
- Your team can enforce tenant context in every request, job, query, cache, and export.
Choose a separate frontend and API when
- The subdomain needs an independent frontend release cycle.
- The API is the intended owner of database access and authorization.
- Your team can operate credentialed CORS, CSRF protection, cookie policy, and token/session revocation correctly.
Final implementation principle
Build the data boundary first, then connect the hostname to it. DNS, rewrites, and TLS make a subdomain reachable; they do not decide which records it may access. WordPress Multisite supplies a documented one-installation, one-database pattern with shared users and separate site content tables. Other stacks can share a database just as safely, but only when table ownership or tenant keys, database privileges, migrations, sessions, and tests are explicit.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
