Hi team,
I am facing a persistent and critical issue on my site where CSS files fail to load or apply on any sub-page, while the homepage works perfectly. I have spent hours debugging and have ruled out all common local/code issues.
- Site:
aipoweredhuman.it
- Working Page: The homepage (
/) correctly loads and applies the stylesheet from /style.css.
- Broken Pages: Any sub-page, for example
/alpha (which is alpha.html in the root of the deploy), fails to apply any style and renders as a plain HTML document.
Here is what we have definitively proven through extensive testing:
- It is not a pathing issue: The
<link> tag in alpha.html uses the correct absolute path: <link rel="stylesheet" href="/style.css">.
- It is not a “File Not Found” issue: The
/style.css file exists and is served correctly, as the homepage loads it without any problem.
- It is not a browser cache issue: We have tried extensive hard reloads (Ctrl+Shift+R) and using the “Disable cache” option in dev tools. The problem persists.
- It is not an HTML/CSS syntax issue: As a final, definitive test, we replaced the link to our local
/style.css in alpha.html with a link to the public Bootstrap CDN. The sub-page /alpha still remained completely unstyled.
This last test proves that something at the platform level is preventing any external stylesheet from being applied to pages served from sub-paths like /alpha.
I am using drag-and-drop deploys and I do not have a netlify.toml or _redirects file in my project that could interfere. The issue started after I tried to add the iubenda policy scripts, but it persists even after reverting to a clean code version without them.
Could you please investigate the server-side configuration, CDN settings, or any potential routing issues for this specific site? At this point, I am certain the problem is not in my code.
Thank you for your help.
@Giulio_Coni Many of your assertions are true, but your conclusions aren’t necessarily correct.
This assertion is provably incorrect (see explanation below):
This ‘definitive test’ may not have been performed correctly:
Which has caused this conclusion to be incorrect:
You definitely shouldn’t be this certain:
Lets step through what can be seen without any access to the code…
Navigating to the root / (with cache disabled) we see:
Navigating directly to /alpha (with cache disabled) we see:
You’ve said that it “fails to apply any style and renders as a plain HTML document”.
But while it is barely styled, it is still styled, and clearly not “a plain HTML document”.
Inspecting the body of the page for example shows that the body is styled with style.css:
If you edit the page to remove the /style.css stylesheet you actually see:
If you edit the stylesheet at runtime it applies:
I’m not sure your /style.css should contain html
Checking what’s in /style.css, there simply doesn’t seem to be much that targets any of the elements seen on the page at /alpha.
You should continue to investigate from the perspective that your own application may be at fault, and you should also attempt to do this locally if possible.
Nathan, you absolute legend. Thank you.
Obviously you were 100% correct. After hours of chasing ghosts in the server, the problem was exactly what you hinted at with your brilliantly witty yet polite sentence: “I’m not sure your /style.css should contain html”. Touché.
Somehow, in the chaos of coding, a massive chunk of HTML ended up living inside my style.css file. The browser was applying the first few rules, hitting the wall of HTML, and just giving up on life.
I’ve now cleaned the file, and everything works perfectly. My sincere apologies for the wild goose chase. You saved me from going completely insane.
Thanks again!
Excellent, that matches what I thought was most likely, so I’m glad that it really was that simple.
If you can, you should start using one of the other ‘Create deploys’ methods too.
The ‘Drag & Drop’ method isn’t as robust as the others, and is prone to various failures/issues/limitations.
