Why is a JSP website showing the wrong path or a 404 error in the UK

If a JSP website is showing the wrong path or returning a 404 error, the problem is usually related to how Tomcat, Apache, and the application’s context path are configured. In a managed hosting setup, this can happen after a deployment, a Java version change, a Tomcat restart, or when the domain is pointing to the wrong application folder. In the UK market, users often see this as a site opening at an unexpected address, while static files work but JSP pages do not.

For JSP hosting, the most important thing to check is whether the request is reaching the correct Java application server and whether the app is deployed under the path that your website expects. If you are using Plesk with a Java hosting extension such as My App Server, you can usually solve the issue without server-level changes by checking the application mapping, service status, and deployment structure.

Why a JSP site can show the wrong path or a 404

A 404 error on a JSP site does not always mean the page is missing. In Java hosting, it often means one of the following:

The application is deployed under a different context path than the URL being requested.
The Apache virtual host is forwarding traffic to the wrong Tomcat instance or port.
The JSP file is placed outside the web application root.
The WAR file was deployed incorrectly or only partially extracted.
The app expects a root URL, but it is actually published under a subpath.
A rewrite rule, proxy rule, or redirect is sending requests to an invalid location.
The Tomcat service is stopped, failing to start, or running an older version of the application.

In practice, the “wrong path” symptom often means that the browser is requesting / while the application is available at /myapp, or the opposite. This is common when a JSP app is moved from local testing to a hosting control panel environment.

Check the actual application URL or context path

Tomcat serves Java web apps under a context path. That context path is the first part of the URL after the domain name. For example:

https://example.co.uk/ — root application
https://example.co.uk/shop/ — application deployed as /shop
https://example.co.uk/app1/ — application deployed as /app1

If the app is deployed as /app1 but the website links point to /, visitors may get a 404. The reverse is also true: if the domain is configured to load the app from the root, but the application is actually under a subfolder, the site can appear broken or redirect to the wrong path.

To verify this in a Plesk-based Java hosting setup, check:

Which domain or subdomain is assigned to the Java application.
Whether the app was installed as a root app or as a named context.
Whether the WAR filename matches the intended context path.
Whether the app’s internal links use relative paths or hard-coded absolute paths.

Common example

If your JSP site was developed to run at / but Plesk deployed it as /myapp, requests to /index.jsp may fail while /myapp/index.jsp works. In that case, you either need to adjust the deployment path or change the app links and configuration to match the actual context.

Confirm that Tomcat or the private JVM is running

In managed Java hosting, a 404 can happen when the service is down or has not started correctly. If you are using My App Server, the application server is managed from Plesk, where you can start, stop, restart, and monitor the service.

Check the following:

The Tomcat or custom app server status is running.
The selected Java version is available and compatible with the app.
The JVM starts without errors after restart.
No recent configuration change broke the startup process.

If the service is stopped, browsers may display a 404, a proxy error, or an unexpected fallback page depending on how Apache is configured. If the service is running but the app still fails, the problem is more likely related to deployment or path mapping.

Review the deployment structure and WAR contents

JSP applications are usually deployed as a WAR file or as an extracted web application directory. The file layout matters. A common cause of 404 errors is placing JSP files in the wrong location inside the archive.

For a standard Java web app, JSP files should usually be under the web root of the application, such as:

/WEB-INF/ for protected classes, configuration, and internal resources
The public web root for pages that should be accessed directly
Any static assets referenced with the correct relative path

Check for these mistakes:

The JSP file was uploaded outside the deployed web root.
The WAR file is missing the main entry page.
The app was packaged with an extra top-level folder, creating a deeper path than expected.
The deployment was interrupted and not all files were extracted.

If your app is called shop.war, Tomcat may deploy it as /shop. If you want the site on the main domain root, the deployment method or application naming may need to be adjusted. In many hosting setups, the domain-to-app mapping is easier to manage in Plesk than by manual file changes alone.

Check Apache proxy and rewrite rules

On hosting platforms, Apache often handles the public domain and forwards Java requests to Tomcat or the private JVM. If the proxy target or rewrite rules are wrong, the site can point to the wrong path even though the application itself is healthy.

Review the following if you have access:

Proxy rules pointing to the correct local port or socket.
Rewrite rules that send all requests to the correct application entry point.
Redirects from www to non-www, or the other way around.
HTTPS redirects that accidentally remove or duplicate the context path.
Rules that rewrite JSP URLs into a folder that does not exist.

A typical issue looks like this: the main page loads, but clicking a link sends the browser to /login.jsp instead of /myapp/login.jsp. That often happens because the app was written with a different base URL assumption than the one used in hosting.

Make sure your app uses the correct base path

JSP applications should not hard-code paths unless the application is designed that way. If a site uses absolute links like /images/logo.png or /login.jsp, those links may break when the app is deployed under a subfolder.

To avoid this problem:

Use relative links where possible.
Build links using the application context path.
Check form actions, redirects, and AJAX calls.
Review static asset paths in JSP templates.

Examples of path problems:

A JSP page redirects to /index.jsp instead of the app base URL.
CSS and images load from the root domain, but the app is hosted in a subpath.
Includes and forwards point to paths that do not exist in the deployed structure.

If you recently moved the application from local development to shared hosting, this is one of the most common reasons for a wrong path or 404.

Check Java and Tomcat version compatibility

Some JSP applications behave differently depending on the Java or Tomcat version they run on. If you changed the runtime in Plesk and the app now shows a 404 after startup, the application may not be loading correctly even if the service appears active.

Look for:

Unsupported Java syntax or libraries.
Servlet API mismatches.
Deprecated configuration settings.
Frameworks that expect a specific Tomcat version.

With My App Server, it is usually possible to select from ready-to-use Java and Tomcat versions or upload and configure a custom version when needed. For small and medium JSP, servlet, and WAR-based applications, this makes it easier to match the runtime to the app without changing the whole hosting account.

Use logs to find the exact cause

When a JSP site returns a 404 or opens the wrong path, logs are the fastest way to confirm whether the request reaches Tomcat, Apache, or neither. Check both web server and application logs if they are available in your hosting control panel.

Useful log clues include:

Requested URL path versus deployed context path.
Tomcat startup errors.
Deployment warnings during WAR extraction.
File-not-found messages for JSP, class, or resource files.
Permission-related errors on web application directories.

Examples of common log findings:

404 for /index.jsp while the app is deployed as /app.
Context failed to start after a bad deployment.
Class not found causing the application to stop loading properly.
Permission denied on the app directory after upload.

Even if the browser only shows a simple 404 page, the logs often reveal whether the issue is deployment-related or path-related.

Step-by-step troubleshooting checklist

Use the following sequence to narrow down the issue quickly:

Open the site URL and note the exact path that returns the 404.
Check whether the app should run at the domain root or under a subfolder.
Verify that Tomcat or the private JVM is running in Plesk.
Confirm the selected Java version matches the application’s requirements.
Review the deployed WAR name and the actual context path.
Check whether JSP files are placed in the correct web root.
Inspect Apache proxy and rewrite rules for path mismatches.
Review logs for deployment errors or file-not-found messages.
Test a direct URL to a known JSP page and a static file.
Restart the app server after fixing configuration changes.

If the site works on a direct Tomcat URL but not on the public domain, the problem is usually in Apache proxying, rewrite rules, or domain mapping. If it fails even on the direct app URL, the issue is likely inside the deployment itself.

How this relates to My App Server in Plesk

In an ITA-style Java hosting environment with My App Server, the normal flow is:

You install or select a Tomcat or Java runtime from Plesk.
The app runs inside a private JVM under the hosting account.
Apache handles the public domain and forwards requests to the app server.
You manage service control, deploy WAR files, and adjust the Java version from the panel.

This setup is useful for JSP hosting, servlet hosting, and lightweight Java applications because it gives you control over the runtime without requiring full server administration. When a 404 appears, the issue is often tied to the control panel configuration, not the code alone.

For small and medium applications, the usual fix is to align these three layers:

Domain mapping in Plesk
Apache forwarding or rewrite rules
Tomcat context path and deployment structure

When to rebuild the deployment

If the app was recently updated and the site now shows the wrong path or a 404, a clean redeploy is often the quickest fix. Rebuild the WAR, remove the old deployment if needed, upload the new package, and restart the service.

You should consider redeploying when:

The previous deployment was incomplete.
The app folder has mixed old and new files.
The context path changed after a rename.
The app was moved from one Java version to another.
Static resources were updated but JSP pages were not.

After redeploying, always test:

The home page
One internal JSP page
One static file such as CSS or image
One form submission or redirect

FAQ

Why does my JSP site work locally but return 404 on hosting?

Local development often runs the app at the root path, while hosting may deploy it under a context path such as /app. The app may also depend on a different Java or Tomcat version, or on rewrite rules that are not present on the hosting platform.

Why do static files load but JSP pages return 404?

This usually means Apache can serve static content, but the request is not being forwarded correctly to Tomcat, or the JSP file is outside the deployed application root. It can also happen if the application context path is different from the URL being used.

How do I know whether the issue is Apache or Tomcat?

If the direct application URL in Tomcat works but the public domain does not, the problem is usually Apache mapping or rewrite configuration. If the application does not load even through the app server URL, the issue is likely in the deployment, runtime, or application files.

Can a wrong Java version cause a 404?

Yes. If the application fails to start due to incompatible Java classes or libraries, the server may not publish the app correctly. In some cases this shows as a 404 instead of a more obvious error page.

Should I use absolute paths in JSP files?

Only if they are built to match the deployed context exactly. In most hosting setups, it is safer to use relative paths or generate URLs from the application context so the site keeps working when the deployment path changes.

What should I check first in Plesk?

Start with the service status, the assigned application path, and the deployment name. Then confirm that the Tomcat or private JVM is running and that the domain is pointing to the correct Java app.

Conclusion

A JSP website showing the wrong path or a 404 error is usually a configuration or deployment issue rather than a code failure. In hosting environments with Apache, Plesk, and Tomcat, the most common causes are a mismatched context path, a stopped app server, an incorrect WAR deployment, or path rules that do not match the application structure.

If you use a managed Java hosting setup with My App Server, the fastest way to resolve the problem is to verify the domain mapping, check the app server status, confirm the deployed context, and review the logs. Once the public URL and the Tomcat application path are aligned, JSP sites usually start working normally again.

Why is a JSP website showing the wrong path or a 404 error in the UK?