amazon-web-servicesvue.jsaws-amplify

404 in DevTool Console for website on AWS Amplify/Vue


I’m running into an issue with my AWS Amplify-hosted website, which is built using Vue 3 and Vite.

When I load the main page (e.g., https://url.de/) and navigate to sub-pages (e.g., https://url.de/contacts), everything works perfectly and no errors are displayed in the DevTools console.

However, when I load a sub-page directly in the browser (e.g., https://url.de/contacts), the page loads correctly, but I see the following error in the DevTools console:

contacts/:1 GET https://url.de/contacts/ 404 (Not Found)

From my research, I understand that this occurs because Vue is a single-page application (SPA) and the server attempts to fetch the requested page directly. In AWS Amplify, I already have the following redirect rule configured to handle SPA routing:

[
  {
    "source": "/<*>",
    "status": "404-200",
    "target": "/index.html"
  }
]

Why does the 404 error still appear in the console and how can I resolve it? The page works fine for end-users, but Google Ads is rejecting these URLs due to the 404 errors.


Solution

  • I think I found a solution.

    Originally, AWS Amplify had this redirect rule automatically configured:

    [
      {
        "source": "/<*>",
        "status": "404-200",
        "target": "/index.html"
      }
    ]
    

    This means that if a route is not found (404), Amplify would serve index.html instead with a 200 status - as far as I understood. For normal browser users, everything worked fine because the SPA router handled the route. However, Google Ads and other crawlers still detected the initial 404, which caused issues with approving sitelinks.

    After changing the rule to:

    [
      {
        "source": "</^[^.]+$/>",
        "status": "200",
        "target": "/index.html"
      }
    ]
    

    everything worked perfectly: no 404 errors are visible in the DevTools, and crawlers no longer see a 404.

    I found this in the documentation of Amplify. There is no explanation about the default 404-200 value, but using "status": "200" as documented solved the issue completely.