Made some "minor" changes to the site
Introduction
And here I am sitting and thinking, how did my site work without all this? I made some structural changes to the site. For the most part, they affected internal linking, to a lesser extent, the content of the site.
About internal linking
I divide my site into 3 levels of pages:
- 1st level, also the top one, contains the home page, the “about me” page, and the contacts page.
- Level 2 is pagination and filter pages, that is, articles, tools and their variations. For example, internal tools, or scrapers, or articles about Django.
- Finally, the 3rd level is the articles themselves.
Initially, the problem was that everything on the 1st and 2nd page levels was loaded dynamically using AJAX requests. Looking at it from the perspective of performance, speed, and accessibility, we can say okay. But the problem is that for Google these pages were empty, and it did not notice the pagination at all; that is, for SEO it was just terrible.
Well, of course, as the main character, I had to fix it or die trying ;). Next, I will describe the corrections for each page level.
Homepage interlinking
I'll start from the top level of the site. Initially, I planned to simply render the home page on the server (SSR), with the ability to additionally load content on it. That is, instead of making AJAX requests from the very beginning, I would make them only after clicking the buttons more... or further. But this solution required me to make the corresponding interface elements for the site, with the corresponding animations. And I was like, Nah, it’s fine ;)
Also, for more flexible management of links and connections between pages, I created a general model for the site. That's what I called it the Website. It is incredibly simple, and now I can change the work of paginators (i.e., the number of loaded elements), which categories to display on the main page, or which links to display in the side menu or footer.
In the future, I plan to improve it, with the emphasis on changing the styles and the general appearance of the site. For example, create a Christmas version of the site ;)
Interlinking pagination pages + filters + tags
And now about the hardest part. It was hard, even for me ʕ ·(エ)· ʔ . And I still couldn't do everything I wanted. For example, loading elements that were before the start page. (For example, you start with the 3rd page, 4,5,6 will load, but the 2nd or 1st will not). Or asynchronous, dynamic loading of posts when you click on any of the tags.
I followed Google's recommendations, for creating an SEO-friendly paginator + infinite feed. And as an example, I used this site. Everything is very cool and clearly explained, but there is not enough direct code that could be relied on or copied.
(Perhaps I will make an article about how to make it by yourself.)
But the paginator is only the first half of the puzzle. The second was the tag system. Here I was able to do and implement everything I wanted, including different tags for different languages or the ability to stack these tags (use several tags at the same time). And the most interesting thing is that all this was done without javascript. Everything is implemented on templates from Django (adding, deleting, and updating tags is all done by templates).
(I might make an article about how to implement your own tag system.)
In theory, tags should have been here from the very beginning of this site's appearance on the internet. But because I had some skill issues, I didn't implement them (^_^).
Cross-linking of the articles
The essence of this level of interlinking is to refer readers to relevant and related content. Increasing time on site and click depth. The following blocks may appear under the “like” and “share” buttons:
- External links used
- Definitions Used
- Related questions
- Related articles
The key word here is may. All of these blocks are optional and may not appear. For example, if external links were not mentioned, then this block is not needed.
I also want to add that everything in these blocks is pulled up automatically, without my participation. Although I have the ability to forcefully make it show the definition or question I need.
(Perhaps I will make an article about how to do this yourself)
Removing news and case sections
And now we come to the root cause of why I started creating a paginator and tag system in the first place. Yes, I just wanted to get rid of these categories. But not just get rid of them, but make them regular tags.
At this moment, the moment of writing and publishing this article. All news has been moved to the articles section with the #News tag added to them, and all cases have been moved to the tools section, but without a special tag. It was simply not necessary.
Adding a gallery
Why and for what purpose did I do it? I’m not sure,¯\_(ツ)_/¯. Maybe I just saw big numbers in Google Search Console, the section about images, and decided that this thing is definitely needed. Or maybe I wanted to create my own “Masonry” (this is one of the design patterns, where each element takes up exactly as much space as necessary so that there are no gaps between them).
Who knows, but I did it, and nothing can be changed.
Conclusions
Honestly, it's too early to draw conclusions. Maybe in a month or two, but not earlier. But in general, I hope that BF (behavioural factors) will improve, in terms of depth and time. Plus, as a bonus, I'll get a buff to views on SERP.
But if I can't judge recent events and updates yet, then I am quite capable of judging my site, which will soon be 1 year old. Although I won't do it here. Spoiler alert: another page with open data on various statistics about my site will appear soon. Roughly speaking, Yandex Metrica or Google Analytics, but built into my site.
Well, that’s all for now. Bye (づ ̄ ³ ̄)づ
0
Used termins
- Django views ⟶ In Django, views are a fundamental component that handle the logic of your web application. They process incoming web requests, interact with models (to retrieve or modify data), and return an HTTP response. In essence, views determine what data gets displayed and how it is presented by associating URLs with Python functions or classes.
- 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.
- Server side rendering (SSR) ⟶ It is a technique in web development where the webpage's content is rendered on the server instead of the client's browser. The primary advantage of SSR lies in its ability to significantly enhance user experience by facilitating faster page transitions and quick loading times.
- Django template ⟶ This is a text document marked up with a special syntax for inserting new code.
- Django model ⟶ Is a database manager used in the Django framework. Implemented via classes and inheritance in python.
Related questions
- How does prop children work? Some components do not know their children in advance. This is especially true for components like Sidebar or Dialog, which are like a "box" into which you can put something. For such components, we recommend using a special prop children, which will pass the child elements directly to the output
- When should I use inline-style vs. CSS? Use inline-styles for dynamic style properties. The CSS alternative provides more advantages, such as auto-prefixing, better debugging, media queries, keyframes.
- 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.