Why the standard plugins for jekyll are very far from ideal.
In this note I will not provide the full code for all components, I will only give snippets and tips on what to pay attention to when assembling a site on jekyll.
File modification time
Every page has at least three timestamp points in different files, page elements, or server responses, and they must all be the same.
- ld+json
"dateModified": "2025-03-07T15:43:42+00:00" - sitemap
<lastmod>2025-03-07T15:43:42+00:00</lastmod> - headres
last-modified: Fri, 07 Mar 2025 15:43:42 GMT
Let’s start with sitemap.xml, in the standard jekyll-sitemap, for pages that are used to output collections on this site, the modification time is taken from the file modification time.
That is, for the page https://webart4.me/en/linux/blog/
the file modification time will be set from /categories/en/blog.md:
{{ page.last_modified_at | date_to_xmlschema }}, but this is not entirely correct.
Because, when modifying, and most importantly when adding a new publication in this category (collection), the modification time
Therefore, we select all publications for a given locale, then those that belong to this category, sort by date, and select the newest one.
1 2 3 4 5 6 | |
Accordingly, the same logic will be used to generate Structured Data.
Server response Last-Modified
This is where things get more interesting.
When you rebuild the site jekyll build --destination , the files will be updated. Even if you use --incremental, you won’t be able to transfer the correct file attributes. Considering some files should have generated values. To do this, we use an elegant and simple script that can be added to the pipeline after each deployment on the server.
nano touch_files.sh
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | |
The script parses sitemap.xml and sets <lastmod> for all files from <loc>.