Ensure custom 404 is giving proper 404 HTTP Status code

Does anyone know if there is a way to know if my custom 404 page is giving the proper 404 HTTP Status code?

I created this 404 page: https://dominickdesigns.space/404/404.shtml

How can I tell if it is giving the proper 404 HTTP Status code? Can I set this in Rapidweaver?

Thank you,

Any of the web/developer tools built into desktop browsers should be able to give you the http response header that includes the response code.

It’s the web server that usually sets the http header, so you can’t really see what exactly you want within RapidWeaver. The preview and simulator use a built in web server but the results can be different than the real server so I wouldn’t rely on what you see RapidWeaver produce.

The link:
https://dominickdesigns.space/404/404.shtml
Will probably give you a 200 ok code as that link is valid.
If you try a URL that doesn’t exist then you’ll see what the end user sees.

If you’re using the standard htaccess

ErrorDocument 404 

then you more than likely will get a 302 Temporary redirect.

thx for the response. My page shows 200 :unamused::sweat:

I am using the .htaccess code that you mentioned.

I think I need to contact my hosting provided to figure out if there is a way to send back 404 response.

Your 404 page exists and loads therefore it should return a 200
Where the 404 should get returned is on a page that does not exist “before” your 404 “recovery/message” page loads.

As stock said and I alluded to earlier, If you link directly to your error page Vital Tech Results - Improving User Experience With Automated Triggers
You will get a 200 OK. That is a valid URL that you can find so It should get a 200.

If you link to a URL within your domain that doesn’t exist say:

Then you will test the 404 error document htaccess directive. If the directive is working correctly you should get a return status of 302. The ErrorDocument 404 directive is a temporary redirect. The 404 is what the Apache returned when the page isn’t found, that triggers the ErrorDocument redirect.

Right now the ErrorDocument for 404 isn’t working.

Looks like you might have an invalid path, but this is what you get:
2020-05-02_10-38-25
Not sure why you are using an SHTML (Server Side Includes) as the extension and not just HTML?

thx for the reply @teefers and @swilliam

My host came back with this reply:

The 404 page was not properly loading due to the following href and src:

href='files/stacks_page_page20.css'
src='files/stacks_page_page20.js

I updated them to this:

404/files/stacks_page_page20.css
404/files/stacks_page_page20.js

when I republish my Rapidweaver site it will override these changes, correct?

they also sent a screenshot showing that it is responding with 404: Screenshot by Lightshot

They also modified the htaccess to this: ErrorDocument 404 /404/404.shtml

any thoughts or suggestions on how to handle this with Rapidweaver?

Click on it, the 404 page isn’t working yet.

when I open this link in private window it shows the intended 404 page.

however, any sub folder like https://dominickdesigns.space/legal/sdfasdf does not show the intended 404 page.

It’s showing the page, just not resolving the CSS and JS file:

If I link to Vital Tech Results - Improving User Experience With Automated Triggers
And I open the console you can see errors and look at the URL path after the redirect:

thank you for the screenshot. Makes sense. Seems like the path in .htaccess works only for the root domain.

I believe I’ve resolved this.

in the 404 directory (name of folder in Rapidweaver is 404) there is an .shtml file.
when I edited this page on the server I added /404/404_files/.... the first / in front of 404 is what made it work. These are the two places I edited on the server (after the website was exported and uploaded from Rapidweaver)

<link rel='stylesheet' type='text/css' media='all' href='/404/404_files/stacks_page_page20.css' />

<script type='text/javascript' charset='utf-8' src='/404/404_files/stacks_page_page20.js'></script>

Question: there is a setting in Advanced in Rapidweaver where you can determine link location (it’s called File Links are and there is a dropdown with three choices. Will the setting here affect how the files are set above?

You own SEO Helper right? I have an error page stack that fixes this for you. I made it specifically for 404 pages.

I don’t see this fixed? It seems to be broken on the now even with a direct link: Vital Tech Results - Improving User Experience With Automated Triggers

Still don’t see a need to use shtml. This extension is only used if you are trying to use server-side includes. Are you using any SSI’s? I don’t see any.

The other settings (Releative to Website Address or Releative to DOCROOT) you think would resolve that. They don’t at least not for stacks pages. Changing the option to Releative to Website Address will resolve most errors. However, for stacks pages, it still places the false directory name into the addresses for the stacks generated CSS and JS files.

I’ve done a bit of experimentation, and the easiest fix is the simplest.
Change the ErrorDocument to use the absolute address instead of the relative address.

  • So in your case (after changing the extension to html and republishing).
  • Change the ErrorDocument 404 /404/404.shtml to:
ErrorDocument 404 https://dominickdesigns.space/404/404.html 

And that should fix the addresses being resolved.

1 Like

oh yes I need to upgrade to the newest version of SEO Helper. Thanks for letting me know. I didn’t know it had that feature.

thanks for the follow up. After I posted I re-published all pages and this overwrote my changes to the .shtml file. I am not sure why I am using .shtml I read somewhere and also heard a a conference that .shtml is supposed to be used for 404 pages. But I appreciate your experience and input. I have a lot of respect for you and people who’ve been in this biz for such a long time.

I moved the .shtml file to the root and edited it again. I also changed the location in .htaccess This way when I re-publish all files it won’t affect this file.

I also tried the absolute path like you suggested. This definitely seems to work. But without editing the .shtml file the sub-directories won’t render the CSS.

That is false RapidWeaver Rumor! You can look up shtml and it’s an odd process not used by many anymore to allow server-side includes (SSI). That’s done by including HTML comments that invoke the server to “grab” what is specified in the include and load it. (SSI also has limited scripting capabilities).

It’s used for things like footers and headers
an example:

<!--#include file="footer.html" -->

When you specify an extension of shtml the server has to “read” every line of code looking for theses directives. Extra overhead if you’re not using them.

As for where this rumor came from, a hosting company that is popular (only in RW) had an Apache directive set in the httpd.conf that allowed you to use a file called 404.shtml as a simple 404 error page. So you could have a “custom” 404-page w/o having to add an ErrorDocument 404 to your htaccess file.

Some how that became a viral RapidWeaver rumor that you should use shtml for 404’s.

I just put together a test that uses Foundation 6 and uses an absolute path for the ErrorDocument 404.

It has navigation, In additioin I added a search (DuckDuckGo stack); things that should be on a 404 as users get 404’s when they are lost.

ErrorDocument 404 https://teefers.com/404-err/

It works no matter what in-error URL you enter.

Check it out: https://teefers.com/nopagehere/ or https://teefers.com/asasdf.html or https://teefers.com/asdfsaf/.

It always ends up as https://teefers.com/404-err/.

Now I don’t know why it didn’t work for you or what you did differently, but my best guess is something didn’t get republished maybe?

@teefers thx again for the follow up. I think I was testing too many variables and that’s why it didn’t work. Although it did work at one point. I appreciate your time and effort. Means a lot to me.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.