How to customize yourown 404 and 500 pages in Django
12.04.2025
15.04.2025
3 minutes
49
0
0
0
0
Initial project setup
Before you start adding custom pages for 404 and 500 responses, you will need to set up your project.
First, create and add a directory with templates to the list of directories, the one in settings.py. And if your directories with templates are called templates/, then you don't have to change anything. But if you call them differently, do the following:
Add a new path to DIRS. You can find this one in the settings.py file.
Secondly, put the site into production mode, that is, disable all debugging processes that Django runs with Debug=True in settings.py. You will also need to add the host name to ALLOWED_HOSTS, as follows:
We do this only because we need to see the result of our changes. And if we don't do this, we will constantly get pages like this, no matter what we do:


And that's about it, but not quite. If, of course, your site is not yet styled, then you can safely skip this chapter to the end. But let's be honest, most likely you already have some styling on your site and that's why you're reading this article. Because you want to complete the layout/styling of the site, or more specifically, the layout/styling of 404, 500 and other responses from the server.
And after completing all the steps described above, you expect to see something like this:

All styles and scripts loaded and applied, it is just beauty ⊂(・ω・*⊂)
But you'll see something like this:


The client failed to get static files from the server. This is confirmed by the developer console. So, how do we get styles, scripts, and media from the server?
To fix this, we need to slightly change the command to start the development server. Namely, start the server without any protective mechanisms, that is, instead of the command:
You must use, this instead:
Now, all static and media files should be available during the production server startup. You remember that we do this in order to see our own 404 and 500 response pages?
Custom 404 page and others
There are several ways to customize the 404 page. The first, and easiest, is to make a 404.html template in any templates/ directory in any application.
The same applies to server responses such as 500, 403, and 400.
The second method offers more customization than the first. So, if you need to further customize pages with server responses 400, 403, 404, and 500, you can write your own view and add whatever you want there. Let's write the most basic view for the 404 response, in a file at Backend/views.py:
All that's left is to connect it to a special handler. In urls.py, in any application, in my case it's always the Backend application, add this line:
There are also handlers for 500, 403 and 400 server responses, they correspond to handler500, handler403 and handler400 respectively. I would like to note that for 4xx codes views must accept 2 arguments - a request and an exception. And for 5xx only a request.
Instead of a conclusion
Here are two ways I know of how to make your own server response pages, like 404 or 500. The first one is, of course, preferable because it is simpler, which means you can make fewer mistakes. The second one is more customizable.
And also, when you are done with debugging, return everything to its original state. That is, DEBUG=True and clear the ALLOWED_HOSTS list. I hope this article was useful to you.
Comments
(0)
Send
It's empty now. Be the first (o゚v゚)ノ
Other
Similar articles
Used termins
- CSS (Cascading style sheets) ⟶ Is a stylesheet language used for describing the presentation of a document written in HTML or XML (including various XML languages like SVG or XHTML). CSS controls the layout, colors, fonts, and overall visual appearance of web pages, allowing web developers to create visually engaging and cohesive designs.
- Django framework ⟶ Is a high-level, open-source web framework for building web applications using the Python programming language. It follows the model-view-template (MVT) architectural pattern and is designed to facilitate rapid development while promoting clean, pragmatic design.
- CORS (Cross-Origin Resource Sharing) ⟶ Is a security feature implemented in web browsers that enables controlled access to resources located outside of a given origin (domain, protocol, and port combination). It is a mechanism that allows web servers to specify who can access their resources and which HTTP methods are permitted for cross-origin requests.
- Website ⟶ Is defined as a collection of related web pages that are typically identified by a common domain name and published on at least one web server. Websites can serve various purposes and can include anything from personal blogs to business sites, e-commerce platforms, or informational resources.
Related questions
- What hosting provider do you use? At the moment I am using beget. So far I'm happy with everything.
- My App doesn't render correctly on the server? If it doesn't work, in 99% of cases it's a configuration issue. A missing property, a wrong call order, or a missing component – server-side rendering is strict about configuration. The best way to find out what's wrong is to compare your project to an already working setup. Check out the reference implementations, bit by bit.
- How do I limit admin access so that objects can only be edited by the users who created them? The ModelAdmin class also provides customization hooks that allow you to control the visibility and editability of objects in the admin. Using the same trick of extracting the user from the request, the get_queryset() and has_change_permission() can be used to control the visibility and editability of objects in the admin.