Plan cPanel Main Document Roots and Subdirectory Applications

A document root is a filesystem location, not a redirect URL. Current cPanel’s domain-management interface does not let you change the Main Domain’s root or the root of names sharing it. A root change, an internal application rewrite and a browser redirect are different solutions.

Identify the actual requirement

• For a separate additional website, create an eligible domain with its own approved root rather than changing the main site’s generated server data.
• For application code kept in a subdirectory while the public URL stays at the root, use that application’s supported deployment/bootstrap procedure.
• For a public URL moving to a subdirectory, plan an explicit redirect and application URL changes; this is not a filesystem-root change.

Do not apply the old server-file recipe blindly

The earlier guide edited cPanel userdata and SSL files, deleted caches, rebuilt Apache and restarted the service. A partial change can leave HTTP, HTTPS and PHP-FPM using inconsistent paths and may be affected by later generated configuration. Do not run root-level cache deletion or service restarts as an account-user workaround.

If an authorized administrator requires a custom server-level change, establish the supported procedure for the exact installed stack, its PHP handler and both virtual hosts. Preserve configuration and application data, prepare rollback and validate a candidate configuration before any approved reload. This review does not certify a universal userdata-edit procedure.

Use the application’s directory layout correctly

WordPress documents arrangements where core files live in a subdirectory while the site address remains at the root. Its entry point, configuration, rewrite rules and site/core URLs must agree. Back up and rehearse first; do not copy a generic rewrite over existing application rules or change URLs without understanding login and asset paths.

For Joomla, Drupal or another application, use its supported version-specific deployment procedure rather than assuming the WordPress arrangement applies. An internal rewrite does not itself move files or secure accidentally exposed directories. A browser redirect changes the public URL and can have separate indexing/caching consequences.

Verify the intended behavior

Test the exact hostname on HTTP and HTTPS, the homepage, nested routes, static assets, login, uploads and relevant jobs. Check PHP-FPM/path errors and redirect loops. Keep recovery copies private; do not expose backups in public_html or restart unrelated services to diagnose one site.

References: cPanel root restrictions and file-movement scope and WordPress directory layouts.

Reviewed October 16, 2026. No userdata file, cache, document root, application URL or server process was changed or tested.