Week 10+11: PDF cluster, blog launch, 143 indexed, and a new compression feature
Combining two weeks into one update since week 10 was heads-down building.
What shipped
PDF cluster (week 10)
Launched 4 PDF conversion pages: pdf-to-jpg, pdf-to-png, pdf-to-webp, pdf-to-tiff. Multi-page PDFs export as a ZIP.
Backend handles it via libvips + pdftocairo for normalization. Took longer than expected.
Blog infrastructure (week 10)
Built a full blog from scratch: JSONB content structure in PostgreSQL, article components, JSON-LD schema. Published 3 posts targeting informational keywords: "What Are HEIC Files?", "How to Convert PDF to JPG", "AVIF vs WebP vs HEIC 2026".
Image compression (week 11)
Added JPG, PNG, WebP compression: same Rust/libvips backend, new /compress/jpg, /compress/png, /compress/webp landing pages. Uses imagequant for PNG (same engine as TinyPNG) and libjpeg for JPG. Real benchmarks: Q=80 gives ~40% savings on JPG, ~36% on PNG. Wrote a technical deep-dive on dev.to about the quality/size tradeoffs.
Numbers
Indexed pages: 75 -> 100 -> 143 (+68 in two weeks)
Impressions (3 months): 520 -> still growing
Blog post already appearing in GSC (what-are-heic-files)
The clicks problem
143 pages indexed, decent impressions, zero click momentum. Top pages by impressions:
- avif-to-png (86)
- avif-to-jpg (67)
- png-to-webp (61)
all sitting at positions 40–50. Need to break into top 20 for any of these to convert.
What's next
Internal linking blog converter (was P0 debt from T10, now done), Semrush on-page fixes for top-5 pages by impressions, and pushing the compression cluster. Longer term: RAW formats (CR2/NEF) for photographers, REST API for B2B.
Week 12 focus: getting at least one page into top 20.
Open to feedback, criticism, and ideas what would you focus on to break through the clicks plateau?
convertifyapp.net: Rust + libvips + Next.js SSG week 11 of 52
Position 40-50 across 143 pages is the classic programmatic SEO plateau, and the honest read is that on-page fixes will not close that gap. Moving from position 45 to top 20 on commodity terms like pdf to jpg or png to webp is an authority problem, not a title-tag problem. You are up against TinyPNG, iLoveIMG, Adobe, CloudConvert, domains with thousands of referring domains. Internal linking does not out-rank that.
Two things I would do. First, stop spreading thin. Pick the two or three pages with the best impression-to-competition ratio and pour links and depth into those instead of shipping more clusters. Second, your RAW formats idea (CR2/NEF for photographers) is buried at the bottom of the roadmap, but it is probably your real wedge. Those terms have far less competition and a clear audience that hangs out in forums and Discords you can actually reach. Head terms reward authority you do not have yet. Long-tail rewards being early and specific, which you can be right now. What is your referring-domain count versus the top five results for your best page?
143 indexed is solid — nice work. I just went through my own indexing setup this week and learned the hard way that a SPA fallback (try_files ... /index.html) can make every fake URL return 200, so non-existent pages look "indexed" but are really just homepage clones — duplicate content that can quietly hurt you. Did you hit anything like that, or were your pages all genuinely distinct from the start? Trying to figure out if it's worth building real landing pages vs. relying on the catch-all.
The 'impressions but zero clicks' part is the piece I'd reframe: at positions 40-50 you're effectively on page 4-5, where real CTR rounds to almost nothing, so clicks won't move until average position does. I'd pause title/meta tweaks and just track position trend for now. On my own small iOS app's site I had ~15 help and landing pages stuck near position 35 for weeks - what finally pushed a few onto page 1 wasn't more pages, it was picking my 3 best converters and aiming every other page's internal links at them, plus a couple of real backlinks each. 143 pages spread thin tends to keep them all mid-pack. If you had to concentrate everything behind just 3 pages, which would you pick?
It's impressive that you were able to build a full blog from scratch in a short amount of time, using a JSONB content structure in PostgreSQL. I'd love to hear more about your decision to use this approach, and how it's working out for you so far. At propfirmpinescripts.com, we've also had to make decisions about content structure and storage, and I'm always interested in hearing about how others are approaching these challenges.
I'm impressed by the progress you've made on your PDF conversion tool and blog infrastructure, particularly the use of libvips and pdftocairo for normalization. As someone who has worked on building a niche digital product store, such as propfirmpinescripts.com, I can appreciate the challenges of handling complex file conversions and building a content structure from scratch. What are your plans for monetizing the PDF conversion tool, will you be offering it as a paid service or using it as a lead generator for other products?
You’ve already got solid technical groundwork, so to break the clicks plateau, prioritize on-page SEO tweaks for your top 3-5 impression pages. Move primary keywords to front of titles, strengthen meta descriptions with clear intent, and add FAQ/collapsible sections targeting related queries. Quick wins also: internal links from blog posts to those converter pages with exact-match anchors.
all these are yet. maybe more clicks still earlier?
It's interesting that you chose to use libvips and pdftocairo for PDF normalization, can you elaborate on what specifically led you to select these libraries over other options. I'm also curious to know how the JSONB content structure in PostgreSQL has been working out for your blog infrastructure, has it met your expectations for scalability and query performance.
On pdftocairo + libvips: the split is deliberate. libvips does the heavy lifting for raster work it's dramatically faster and lower-memory than ImageMagick.
On JSONB for the blog: honestly it's been a good fit for my scale, with caveats. The content is an array of typed blocks 'section', 'callout', 'comparison_table' and storing that as JSONB. It very simple for me and I can suppot this solution
building a custom blog structure using jsonb in postgres is pure engineering grit lol. most builders just drop a bloated ghost or headless cms wrapper and call it a day.
143 pages indexed in two weeks is a massive momentum win. being stuck at positions 40-50 just means you're in the evaluation sandbox.
i'd definitely hold off on adding new raw photographer formats for week 12 and spend 100% of the energy on those semrush on-page fixes and interlinking the content cluster. how are you tracking the semantic data drift on google search console as you roll out these internal link updates?
way, blog in postgres jsonb it is enguneering grit? how need save data? what about tracking, I newbie in seo, and I only study do this, how it do? I don't have correct mechanism. Maybe you now right way for this?
haha it's 'grit' because with a single postgres jsonb column you're basically raw-dogging the schema layout. if you want to add a new custom block type or change how post metadata is handled later, you have to write custom code to parse and filter it manually in your frontend instead of letting a standard relational database or a structured cms handle it. but for solo builders, it's awesome because it keeps your setup incredibly lightweight and flexible.
for tracking data drift and seo keywords when you're just starting out, you definitely don't need to build a heavy logging mechanism from scratch. what works perfectly is setting up a clean workflow automation pipeline to fetch your daily impressions or positions from google search console. you can pipe those metrics straight into an organized tracking database like notion to see exactly when your ranks shift from position 50 into the top 20. keeping it automated means you don't waste hours on manual entry.
It is what understand and doing now.
The technical progress is strong, especially the Rust/libvips backend, PDF cluster, compression pages, and the B2B API direction.
The click problem may not only be an SEO problem though. “Convertifyapp” explains the utility, but it also puts you in the same mental bucket as every other converter site. When users see positions 40 to 50, they are probably comparing dozens of nearly identical “convert X to Y” tools, so trust and memorability matter more than usual.
I’d think about the brand frame before you build too many more indexed pages around it. If this stays a simple converter library, the current name is fine. But if the longer-term direction is image/PDF infrastructure, compression, RAW formats, and a REST API for B2B users, the name should feel more like a serious file-processing platform than another SEO converter site.
Xevoa .com would fit that broader direction better. It keeps the product on your side: same fast conversion/compression engine, but with a cleaner platform name if you move beyond consumer landing pages into API, developer, and business use cases.
For week 12, I’d focus on getting one cluster to feel more trustworthy and differentiated, not just better internally linked.
Convertify don't sound how serious company or brand?
I’d separate “clear” from “serious.”
Convertifyapp is clear. Nobody will misunderstand what it does. That is a strength for SEO pages.
But for the bigger direction you’re building, the question is different: will a B2B user or developer remember it as a serious file-processing platform, or will they mentally place it beside every other free converter site?
That matters because your product is already moving beyond simple conversion. Rust/libvips backend, compression, PDF clusters, RAW formats, and API direction all suggest something more durable than a utility page network.
So the risk is not that Convertifyapp is bad. The risk is that the product becomes stronger than the brand frame around it.
That is why Xevoa.com felt like a better long-term shell to me. It is short, clean, platform-like, and does not trap you inside the “converter app” category. You could still keep all the same conversion/compression value, but present it under a name that feels more serious as the B2B/API side grows.
I would pressure-test that before you build too many more pages, docs, and product surfaces around the current name.
Thank you for explaining, exactly it good point.
Yes, exactly.
Convertifyapp can work for the current SEO utility layer, but the stronger question is what name can carry the product if the API/B2B side becomes the real business.
Once developers, teams, or businesses start using it as file-processing infrastructure, the brand needs to feel less like another converter page and more like a platform they can remember and trust.
That is why Xevoa stood out to me. It gives you a cleaner shell for the bigger direction without losing what you already built: fast conversion, compression, PDF/image processing, and API use cases.
If you are seriously thinking about that future platform direction, I would compare both names now before more docs, pages, and product surfaces are locked around Convertifyapp.
I understand. Thank you.
This comment was deleted 2 days ago.