Two months in, 75 pages indexed, zero blog posts. That was the plan — ship converter pages, get them indexed, figure out the informational content later.
Then one keyword changed my mind.
The number that changed things
I've been tracking keywords for Convertify across image conversion queries. Most sit between KD 35 and 86 competitive, slow to move, need real backlinks to crack.
While reviewing the list this week I noticed "what are heic files" 3,600 searches per month, KD 20.
For context:
-
heic to jpg-> KD 67 -
convert png to pdf-> KD 43 -
avif vs webp-> KD 35 -
what are heic files-> KD 20
The SERP is surprisingly weak for a query with this volume. Most results are generic explainers rather than tools solving the problem directly. No converter tool has a proper dedicated page ranking for it.
That felt like the right moment to start.
The logic behind it
The user searching "what are heic files" is usually an iPhone owner who just tried to send a photo somewhere and got confused. They're a couple of clicks away from needing a converter.
The path I'm betting on:
- Land on
/blog/what-are-heic-files - Understand that HEIC isn't universally supported
- Follow an internal link to
/heic-to-jpgor/heic-to-pdf - Convert
Informational content converts when the internal linking is tight. A blog post with no clear path to the tool is just a vanity page. The goal here isn't content for content's sake — it's closing the loop between someone learning about a format and actually solving their problem.
What I built this week
The main work was a PDF cluster three new converter pages plus the blog infrastructure.
HEIC -> PDF turned out to be more interesting than expected. PDF has no HEVCDecode filter the spec only defines DCTDecode (JPEG), FlateDecode, and JPXDecode. That means HEIC always requires a transcode to JPEG before embedding. JPG -> PDF by contrast is literally lossless bytes go in untouched. I wrote the full explanation in the page content because this is exactly the kind of depth that thin competitor pages skip.
PDF -> PNG uses pdftocairo for rendering. pdftocairo runs about 3–4x faster than ImageMagick at 300 DPI and produces noticeably better anti-aliasing on text. libvips has a pdfload wrapper that also calls poppler under the hood, so the pipeline stays consistent.
For the blog itself I went with PostgreSQL instead of MDX files. Every new MDX post requires a deploy for a solo developer writing irregularly, that friction compounds quickly. The blog_posts table uses the same JSONB content structure I already use for landing pages, so the renderer was already built. Adding the blog was mostly schema and new routes.
Where things stand
- Indexed URLs: 75 -> 82 (target after new pages)
- Impressions last 3 months: 509
- Blog posts live: 0 -> 2 (target by end of week)
The cross-links I added in week 9 across 64 converter pages should start appearing in GSC by Thursday. Right now I'm prioritizing site structure and internal linking before investing time into backlink outreach. Structural fixes take a few crawl cycles to surface each one is slow feedback, but it compounds.
Why this feels different
The interesting part about SEO at this stage isn't traffic yet it's feedback loops.
You ship a structural change, wait through a few crawl cycles, and slowly learn which assumptions were right. Most changes take weeks to show up. You're essentially running experiments with a 3-week delay on results.
The KD 20 HEIC query is the first time the feedback loop feels short enough to actually compound. If a new domain can rank for KD 20 in a reasonable timeframe, that's a signal worth building on.
Next check is Thursday's GSC analysis.
Convertify is a free image converter built with Rust + libvips and Next.js SSG.
Week 1–10 archive: https://dev.to/serhii_kalyna_730b636889c