I largely subscribe to what is described here, and believe sincerely that any piece of work should be an opportunity to do a little bit of cleanup.
Though, one counter-argument in favor of putting refactoring tickets on the backlog is that it can be useful to make the cost of cleaning the codebase more visible to the higher-ups.
This is especially interesting if each sprint you organize to take up the feature tickets AND the refactoring tickets at the same time. If you work in a place that refuses to pick up the refactoring, then indeed the "hidden" approach described here is probably a good way to go.
I personally use a combination of quarto to statically render markdown files and hosting on GitHub pages because I don't want to bother with the self hosting for now.
In the past I used a combination of R-markdown with a nginx server but decided to move to a simpler solution
Though, one counter-argument in favor of putting refactoring tickets on the backlog is that it can be useful to make the cost of cleaning the codebase more visible to the higher-ups.
This is especially interesting if each sprint you organize to take up the feature tickets AND the refactoring tickets at the same time. If you work in a place that refuses to pick up the refactoring, then indeed the "hidden" approach described here is probably a good way to go.