Every SEO guide for indie builders eventually tells you to publish consistently. Then you look at what "consistently" means, and it is two posts a week forever, and you have a full time job.
So most side projects do the sensible thing and publish nothing. Which is also a mistake, just a cheaper one.
There is a version in between, and it looks less like a content calendar and more like a spreadsheet of pages that each have a reason to exist.
Why "just write 100 blog posts" fails for side projects
Volume strategies assume you can absorb a lot of failure. A media company publishing 400 posts a year is fine with 380 of them doing nothing, because the twenty that hit pay for the rest.
You do not have 400 posts in you. You have maybe fifteen before you start resenting the project.
So a strategy built on failure absorption is exactly the wrong shape for you.
There is a second problem. Thin posts are not neutral. A site where most pages are filler is a site where a crawler has to work to find the good pages, and where a visitor's first impression is often something you wrote in twenty minutes to hit a quota.
The pages that earn a URL
Strip it back and there are three kinds of page worth having:
1. One page per thing your product does. Not one page for your product. One per job. If your tool splits images and merges images, those are two pages, because they are two different searches by two different people with two different problems.
2. A hub that lists them. Somewhere to land, somewhere to link from, and the page that ranks for your category term.
3. Articles that answer real questions. Not "the ultimate guide to images." Questions you have actually been asked, or that the tool page raises and cannot answer without becoming a wall of text.
That is it. For a four tool project it is about ten pages, and ten pages is a weekend, not a year.
A real example: how this site is structured
Piknova has four tool pages, one hub, five blog posts, and one guide. That is the whole surface. Here is how it is put together, because the mechanics are more useful than the theory.
Every tool is one registry entry. A single object holds the tool's id, slug, route, category, access rules, and all of its page content: the SEO title and description, the structured data, the hero, the FAQ. Nothing about a tool is typed twice.
The routes, metadata, structured data, sitemap, and OG image all read from that entry. Adding a tool means adding a config object and a thin page shell. The sitemap picks it up with no edit. The OG card is generated per slug. The WebApplication structured data is built from the same fields as the visible copy, so they cannot drift apart.
This is what programmatic SEO looks like at small scale. Not thousands of generated city pages, just refusing to hand-maintain the same facts in five places.
A page has to earn its URL. There is a rule written into the project: a platform variant page (/tap-the-post-x runs the same engine as the image splitter) only gets its own URL if it can say something true that the base tool page cannot. Otherwise it is a section on the base page. That rule has killed more page ideas than it has approved, which is the point.
The rule for whether a page deserves to exist
Before creating a page, answer both:
What query does this page answer better than any page I already have?
If the answer is "the same thing my tool page answers, but longer," you are about to compete with yourself. Two of your own pages splitting the same intent is a real cost, and it is entirely self inflicted.
What can this page say that my other pages cannot?
If the answer is nothing, it is a section, not a page.
What breaks when you rename a URL
Slugs get named badly early, because you name them before you know what the thing is. Then you want to fix it.
Fixing it is fine. Fixing it without a permanent redirect is not, because the old URL is where any accumulated history lives, and dropping it throws that away for a tidiness win.
Concretely, this project has three redirects it will carry forever:
/tools/split-xto/tools/image-splitter, from when the slug was spelled out/tools/yt-thumbnail-downloaderto/tools/youtube-thumbnail-downloader, same reason/tools/screenshot-editorto/tools, from a tool that shipped in February 2026 and was removed in July
That last one is the interesting case. The screenshot editor is gone and no equivalent exists, so there is nowhere honest to send that traffic except the hub. It still beats a 404. Google's documentation on redirects covers the mechanics.
What blog posts are actually for
Not traffic, mostly. Their real jobs:
- Answering the question the tool page raises. The splitter page explains what the tool does. It should not also contain 1200 words on why grid posts work. That is a post.
- Catching long tail queries. Specific, low competition phrasings that no tool page would target directly.
- Being linkable. People link to explanations. Very few people link to a tool page unprompted.
- Being honest in a way a landing page cannot. A tool page saying "we do not do this yet" reads as weakness. An article saying it reads as trustworthy.
- Carrying structured data a tool page cannot. An article with a genuine FAQ section can mark it up as FAQPage, as long as the questions are actually visible on the page.
If a post idea does none of those four, it is a post that exists to exist.
A realistic 90 day plan
For a side project with roughly two hours a week:
Weeks 1 to 3: one page per job your product does
Real copy, a real FAQ, correct titles and descriptions. Do not write a blog post yet.
Weeks 4 to 5: the hub page and internal links
Every tool page links to the others it pairs with.
Weeks 6 to 8: structured data and plumbing
Sitemap, canonicals, OG images. Generate it from config so it does not rot.
Weeks 9 to 12: now write three or four articles
Chosen from questions people actually asked you.
Most people invert this and start at week nine. That is why their tool pages are still thin a year later.
Frequently asked questions
Do I need a blog to rank my side project on Google?
No. Most side projects rank on tool pages, not blog posts. A blog helps when there are real questions the tool page cannot answer without getting cluttered. Writing posts purely to have posts builds a liability.
How many pages does a side project actually need?
One per thing your product does, a hub that lists them, and a handful of articles answering real questions. For a four tool project that is roughly ten pages.
What is programmatic SEO for a small tool?
Generating pages from structured data instead of writing each by hand. For a tool site: one registry entry per tool that drives the route, the metadata, the structured data, and the sitemap entry.
Should I change my URL slug if it is badly named?
Only with a permanent redirect from the old URL, added in the same change. Without it you throw away whatever history the old URL had.
How long does it take a side project to rank?
Longer than you want, and it varies too much for anyone to give you an honest number. What you control is whether the page deserves to rank when the crawler arrives. Publishing more pages does not speed it up.
Is it worth doing SEO for a free tool with no revenue?
It is the cheapest distribution a free tool can get, because utility search intent is unusually specific. Someone typing "how to split an image into 4 parts" wants exactly one thing.
The short version
Build the pages that answer a real query, generate them from one source of truth, and write an article only when you have something a landing page cannot say. Then stop.
