DEV Community: Convertica

Half the directories promising you a dofollow backlink are serving nofollow

Convertica — Mon, 10 Aug 2026 14:26:07 +0000

I spent a day submitting a side project to launch directories, and I made a rule for myself before I started: no listing goes live until I have measured what its outbound link actually looks like. Not what the pricing page claims. What the HTML says.

I looked at about fifteen. Six of them do not give you the link they advertise. One advertises it in a way that is technically true and practically useless. And one had already quietly downgraded a link I earned weeks ago, without telling me.

Here is the measuring, the results, and the two traps I walked into so you do not have to.

The measurement is one curl and one grep

Everything below comes from this. No tools, no subscriptions.

curl -sL -A "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Chrome/127 Safari/537.36" \
  "https://directory.example/listing/some-product" > page.html

# 1. Is the listing page even indexable?
grep -oiE '<meta[^>]+name="robots"[^>]*>' page.html

# 2. What does the link to the product's own site look like?
grep -oE '<a [^>]*href="https?://theproduct\.com[^"]*"[^>]*>' page.html

Three things matter in the output, and people usually check only the second one.

Is there a <meta name="robots"> with noindex? A dofollow link on a page Google will not index is worth roughly nothing. Two of the directories I checked are noindex on exactly the page that carries your link.

Does the anchor carry nofollow? rel="noopener noreferrer" is a dofollow link. rel="nofollow noopener noreferrer" is not. That single word is the whole product being sold.

Is there an <a> at all? This is the one that surprised me, and I will come back to it.

Do this on three or four different listings, not one, and pick listings that look like free ones rather than the ones featured on the homepage. That is the entire trick, and it is the reason the numbers below look nothing like the marketing.

The results

Tier-gated: the word "do-follow" appears only in the paid column.

One large launch board states it plainly in its own FAQ, which I only found after checking the listings:

Free launches need the badge on your site and wait their turn in the queue. Premium skips both: you choose the exact date, get a guaranteed homepage feature, and keep a permanent do-follow backlink, with no badge required.

The free column lists "public product listing" and "badge required on your site" and says nothing about rel. I sampled eight live listings: four came back rel="noopener noreferrer", four came back rel="nofollow noopener noreferrer". A clean split. Their own JavaScript settles it, because the launch form carries a per-plan flag called backlink and a paid add-on to switch it on.

So the free tier there is: host our badge forever, get a nofollow link. That is not a trade, that is a favour.

Silently downgraded after the fact. I had a badge in my footer from a directory that promised three dofollow links in exchange for it. I measured it again on the way past. All three links now read rel="nofollow noopener noreferrer". Nobody emailed me. The badge had been working for free for weeks. It is out of the footer now.

The lesson is not that they are villains. It is that a badge-for-link deal is one you have to re-check, because only one side of it is enforced automatically. They verify your badge on a schedule. Nobody verifies their rel but you.

No link whatsoever. This is the one worth knowing about. On the big software review sites in one particular network, I could not find the vendor's link at all. Not nofollow. Absent. The "Visit Website" control is a <button>, the redirect happens in JavaScript, and the header of the page says the quiet part out loud:

We may earn a referral fee when you visit a vendor through our links.

Which makes sense once you say it: a tracked affiliate redirect is not a citation, and there is no reason for them to make it one. If you are chasing those listings, chase them for the buyer traffic and the reviews. There is no link to win.

The no-op rel token. One directory ships rel="noopener noreferrer dofollow". There is no such thing as rel="dofollow". It is a token search engines ignore entirely; the link is dofollow because nofollow is absent, not because somebody typed the opposite. Harmless in itself, but seeing it told me something about how carefully the rest of the site was built, and its product pages turned out to be noindex anyway.

And the honest ones. Two sites measured exactly as advertised. One free tier says "get 1 dofollow link" and means it. Another puts "permanent dofollow backlink" in the free column, and its live listings are server-rendered index, follow with rel="noopener noreferrer" on the product link. On a third, I sampled eight random launches and got eight dofollow links with no nofollow anywhere, which told me its rel is not tier-gated at all: what its paid tier sells is homepage placement, not link equity.

Those three got a badge in my footer, and I would do it again. The point of measuring is not that directories are a scam. It is that you can tell the fair ones from the rest in two minutes, and then spend your footer on the fair ones.

Two traps I walked into

I broke my own audit with a hostname filter. My first pass over one directory reported "no outbound links found" on every listing, which was nonsense. My script excluded any anchor whose tag mentioned the directory's own domain, to skip internal navigation. But their outbound link looked like this:

<a href="https://theproduct.app/?ref=https%3A%2F%2Fdirectory.example%2F" rel="noopener noreferrer">

The directory's domain sits inside the ref parameter, so my filter threw away the exact link I was measuring. If an audit tells you a page has zero outbound links, suspect the audit first. Filter on the parsed hostname of the href, not on the raw tag text.

Your bot protection can make your badge invisible. Several of these sites verify the badge by fetching your homepage from their own servers and looking for it. If you sit behind a bot-challenge product, those datacenter requests can get a JavaScript interstitial instead of your HTML, and verification fails while the badge is plainly there in a browser.

I could not see their side, so I reproduced what I could: from my own IP the page returned the badge under every Accept-Language variant and under python-requests, node-fetch, axios, Go-http-client and curl user agents. So neither the UA nor the cache was the problem. The proof came from the directory itself: on its review step, its own metadata crawler had filled my product title in as "Just a moment...", which is the title of a Cloudflare challenge page. Their crawler had been talking to the challenge, not to me.

Two other directories' verifiers sailed through on the same day, so this is per-crawler, not a blanket block. Turning the protection off for the length of one verification click fixed it. If a verifier insists your badge is missing, check whether the site can see your HTML at all before you start editing your footer, and if the directory offers DNS TXT verification instead, that path skips the fetch entirely.

What I would tell myself before starting

Check robots, check rel, and check that an <a> exists, on three or four free listings. Do it before you spend a footer slot, because footer slots are finite and every badge is a permanent obligation the other side will keep checking. Re-measure the badges you already have, because at least one of mine had gone nofollow without a word. And keep the row short. Six badges reads as a community. Twenty reads as a link scheme.

None of this is exotic. It is a curl, a grep, and the discipline to look at the free tier instead of the pricing table.

I write these while building Convertica, a set of browser PDF and image tools with no signup wall, which is the side project I was submitting all day. The engineering half of the story is mostly fonts: getting text you type into a PDF to come out as real selectable text in Cyrillic, Arabic and Devanagari instead of boxes is most of the work behind the editor, and it is a better story than directory rel attributes. Maybe next time.

A honeypot field made every Arabic page on my site render blank

Convertica — Mon, 03 Aug 2026 17:46:01 +0000

Convertica runs in seven languages. Six of them read left to right, and Arabic does not. That single difference cost me an embarrassing amount of debugging time.

The symptom

Every Arabic converter page looked completely normal in my browser. Then I ran Lighthouse against one of them and the screenshot came back empty. Not broken, not half painted. White.

Same URL, same server, same HTML. Fine in Chrome, blank in headless Chrome. And headless Chrome is roughly what Google, Bing and every link preview bot see.

The culprit

Sitting in the form on every converter page was a spam honeypot. An input no human should ever fill in, parked far outside the viewport:

<input type="text" name="website"
       style="position: absolute; left: -9999px; opacity: 0"
       tabindex="-1" autocomplete="off" aria-hidden="true">

This is one of the oldest tricks in the book, and it is harmless. In a left to right document.

Why direction changes everything

In an LTR document, overflow past the left edge is unreachable. The browser clips it, no scrollbar appears, nothing moves. The honeypot sits in dead space.

Set dir="rtl" and the scroll origin moves to the right edge. Now that leftward overflow is real scrollable canvas, so the document is about ten thousand pixels wide with the actual content bunched up at the far right.

My browser opens an RTL page already scrolled to its origin, so I never saw anything wrong. A headless renderer taking a screenshot starts at x = 0, which in that document is the far left corner. Nine thousand pixels of nothing.

The fix

One property.

/* before */
position: absolute; left: -9999px; opacity: 0;

/* after */
position: absolute; inset-inline-start: -9999px; opacity: 0;

inset-inline-start is the logical form of left. It follows the writing direction, resolving to left in LTR and right in RTL. The honeypot lands outside the viewport on the side the document is already ignoring, and the canvas never grows.

What I took from it

Every offscreen hack you inherited from a 2010 blog post deserves a second look once you ship RTL. Honeypots, skip links, hidden measurement divs, homegrown sr-only classes. Trade left and right for inset-inline-start and inset-inline-end.
Your own browser is the worst possible test for this class of bug, because it hides the failure by scrolling to the correct origin for you. Render the page headless and look at the actual pixels.
If one locale quietly stops earning impressions while the rest are fine, suspect the renderer before you suspect the content.

The Arabic pages have been rendering properly for a while now. The tools live over at Convertica, and the Arabic side is the one that taught me this.

Convert PDFs and Office files without leaving Claude or Cursor

Convertica — Fri, 17 Jul 2026 22:09:38 +0000

I kept hitting the same tiny annoyance. I would be deep in a chat with Claude, working through some documents, and then I would need one of them as a Word file. Or a client would send a HEIC photo that nothing wanted to open. Every time it meant leaving the editor, finding a converter site, uploading, downloading, and coming back. Small friction, but it adds up over a day.

So I wired the conversion step directly into the assistant using MCP. Now I just ask for it in plain language and the file lands in my folder. This post shows how to set that up.

What MCP gives you here

The Model Context Protocol lets an AI client call external tools in a structured way. Instead of the model guessing or writing throwaway scripts, it calls a real tool with real arguments and gets a real result back. A conversion server is a good fit: the model does not need to know how to render a PDF, it just needs to know that a convert_file tool exists and what it accepts.

I used the Convertica MCP server because it wraps a whole batch of conversions behind two tools, but the pattern applies to any MCP server you like.

Setup

You need Node 18 or newer and an MCP client. I will show Claude Code and the generic config that Cursor, Windsurf and Claude Desktop all understand.

You also need an API key. Convertica issues one from the account dashboard once you have a subscription, and the same key works for the web API and the MCP server.

Claude Code, one line:

claude mcp add convertica -e CONVERTICA_API_KEY=cvk_live_xxxx -- npx -y convertica-mcp

Any other client, drop this into the MCP config:

{
  "mcpServers": {
    "convertica": {
      "command": "npx",
      "args": ["-y", "convertica-mcp"],
      "env": { "CONVERTICA_API_KEY": "cvk_live_xxxx" }
    }
  }
}

That is the whole install. npx pulls the package on first run, so there is nothing to clone or build.

Using it

Once the server is connected, you talk to it the way you talk about anything else. A few that I actually use:

Convert ~/Downloads/contract.pdf to Word

Merge these three PDFs into one and compress the result

Turn this HEIC photo into a JPG

Render https://example.com as a PDF

The model picks the right tool, reads the local file, sends it off, and writes the result next to the original. If you are curious what is available, there is a list_converters tool that returns the full catalog with each tool's options, so you can ask "what can you convert?" and get an honest answer instead of a hallucinated one.

Under the hood there are two tools. list_converters returns the catalog. convert_file takes a tool name, one or more local file paths, and an options object, then saves the output. Everything is typed, so the model gets a clear error if it asks for something that does not exist rather than failing silently.

Why a hosted converter instead of a local library

You could do a lot of this locally with libraries. I went with a hosted API for two reasons.

The first is coverage. PDF to Word done well is genuinely hard, and so is Office rendering, HEIC decoding, and PDF/A conformance. Stitching together five libraries and keeping them working is a project in itself. One API that already handles thirty five conversions is less code I own.

The second is that it keeps the client thin. The MCP server is a small wrapper with no native dependencies, so npx just works on any machine without a build step or a headless browser.

The tradeoff is that files leave your machine for the conversion. Convertica deletes processed files right after the response, which was good enough for my use, but if you are handling something sensitive, read the provider's retention policy first and decide for yourself.

Wrapping up

The setup is a few minutes and the payoff is that a whole category of context switching disappears. Ask for the file you want in the format you want, keep working.

The server is open source (MIT) if you want to read it or adapt the pattern to your own API:

Repo: https://github.com/convertica-net/convertica-mcp
npm: https://www.npmjs.com/package/convertica-mcp
The API it calls: https://convertica.net/api/

If you build something similar for a different service, I would like to see it. The two-tool shape (a catalog tool plus a typed action tool) turned out to be a clean way to expose a broad API to an assistant without overwhelming it.

Automating the PDF Conversions You Keep Doing by Hand

Convertica — Tue, 14 Jul 2026 13:48:34 +0000

Most PDF work is a one-off: a file lands, you convert it, you move on. But some of it repeats. A folder of scanned invoices every Monday. Statements that need to become spreadsheets before month-end. Reports that arrive as PDF and have to go out as Word. If you are doing the same conversion by hand every week, that is a job for a script, not a person.

Here is how I moved those repeat conversions off my plate.

First, the ten-second check that saves you

Before automating anything, know which kind of PDF you are feeding the pipeline. Select a word in the file. If it highlights, the text is real and conversion is clean and deterministic. If nothing highlights, the page is an image, and you need OCR in the loop, which is still fine but adds a recognition step you should spot-check. Automations break most often because someone assumed every input was a native PDF when half of them were scans.

Wrapping a converter in a script

The pattern is boring in the best way: watch a folder or a queue, POST each file to a conversion endpoint, write the result somewhere. I use Convertica for the conversion step because it has a free API and does not require an account, so there is no OAuth dance to script around. A single conversion is just a POST with the file:

curl -X POST https://convertica.net/api/v1/pdf-to-word/ \
  -F "file=@invoice.pdf" \
  -o invoice.docx

Drop that into a loop and a cron entry and the Monday-invoices chore runs itself:

#!/usr/bin/env bash
set -euo pipefail
IN=./incoming
OUT=./converted
mkdir -p "$OUT" "$IN/done"
for f in "$IN"/*.pdf; do
  name=$(basename "${f%.pdf}")
  curl -fsS -X POST https://convertica.net/api/v1/pdf-to-excel/ \
    -F "file=@${f}" -o "${OUT}/${name}.xlsx" \
    && mv "$f" "${IN}/done/"
done

# every Monday at 6am
0 6 * * 1 /home/me/scripts/convert-invoices.sh >> /var/log/convert.log 2>&1

The set -euo pipefail and curl -fsS matter more than they look. Without them a failed conversion writes a zero-byte file, your mv marks it done, and you lose the input silently. Fail loudly instead.

The parts people skip

Idempotency. Move processed files out of the input folder (or track them) so a re-run does not convert the same file twice.
Scanned inputs. If the batch might contain scans, expect OCR and add a sanity check on the output. A zero-length or suspiciously tiny result usually means a bad scan.
Cleanup. Whatever service you use, know its retention. Convertica deletes uploads from the server after a short window, which is what you want for statements and contracts rather than throwaway samples.
Secrets stay home. For genuinely confidential documents I generate the file from source rather than round-tripping it through any external service, mine included. Automation is for the routine stuff, not the crown jewels.

Do not forget the passwords

One thing that quietly breaks batch jobs: a password-protected PDF in the input. There are two kinds, and they fail differently. An owner-password file (restrictions only) usually still converts. An open-password file is encrypted and will not convert without the password, and no tool bypasses real encryption, so your script should catch that case and set the file aside for a human rather than retrying forever.

The point

The work has not changed. Files still need to be smaller, converted, and machine-readable. What changed is that the repetitive slice of it belongs in a five-line script and a cron entry. Spend the ten seconds to check text-versus-scan, fail loudly, respect retention, and the Monday chore stops being a chore.

PDF Chores You No Longer Need a Desktop App For

Convertica — Tue, 14 Jul 2026 12:49:03 +0000

Every few weeks a PDF lands on my desk that needs something done to it. Shrink it so an email will accept it. Pull a table into a spreadsheet. Merge four scans into one file. For years the reflex was to open a heavy desktop app, or worse, to pay for one just to run a two-minute task. That reflex is out of date. Almost all of it now runs in a browser tab, and some of it runs from a script.

I want to walk through the ones I actually use, and where the line sits between "do it in the browser" and "automate it."

The one check that saves you every time

Before touching any PDF tool, find out what kind of file you have. Select a word on the page. If it highlights, the text is real and any conversion will be clean. If nothing highlights, the page is an image (a scan), and you need OCR to get text out of it.

This sounds trivial, but it explains most "the converter mangled my file" complaints. A native PDF converts faithfully. A scanned one goes through character recognition, which is good but not perfect, so you review the output. Knowing which you have sets your expectations correctly before you start.

Shrinking a PDF for email

Mail providers still cap attachments low: Gmail at 25 MB, Outlook around 20, plenty of corporate servers at 10. A 300-DPI scan blows past all of them.

Compression re-encodes the images inside the file while leaving the text sharp. Medium compression is the sweet spot for email: the file drops several times over and you will not see the difference on screen. Keep maximum quality only when the destination is a professional printer.

Getting tables out of a PDF and into a spreadsheet

This is the one that used to eat my afternoons. Copy-pasting a PDF table into a spreadsheet collapses it into a single column of run-together text, because a PDF stores text at fixed coordinates, not as a real grid. A proper conversion reads the position of every value and rebuilds actual cells, so numbers land under the right headers.

For one-off files, a browser tool is the fastest path. When it becomes routine, say a nightly batch of statements, this is where automation earns its keep.

When to reach for an API instead of a tab

The browser is right for occasional work. But if you are converting the same kind of document on a schedule, or building a feature into your own app, you do not want a human clicking upload. That is the point where a free API pays off.

I have been using Convertica for both sides of this. The web tools cover the ad-hoc jobs (compress, merge, split, PDF to Word or Excel, unlock, and so on) with no signup, and there is an API for wiring conversions into a pipeline. A typical call is nothing more than a POST with the file:

curl -X POST https://convertica.net/api/v1/pdf-to-word/ \
  -F "file=@report.pdf" \
  -o report.docx

Uploaded files are removed from the server after a short window, which matters when the documents are statements or contracts rather than throwaway samples. For anything genuinely secret, I still generate the file from source rather than round-tripping it through any service, mine or otherwise.

A note on PDF passwords, since it trips people up

PDFs carry two kinds of password and they behave very differently. An open password encrypts the file: without it, nothing can read the content, and no tool bypasses real encryption in seconds regardless of what its landing page claims. A permissions password only disables copy, print, or edit while letting the file open, and that kind was never strong protection to begin with.

The practical takeaway for developers: if you need to actually secure a document, set an open password and share it out of band. Do not rely on permission flags, because most readers and libraries ignore them.

The shift, in one line

The work has not changed. Files still need to be smaller, mergeable, and machine-readable. What changed is that none of it requires a paid desktop install anymore. Occasional jobs go in a browser tab, repeated ones go through an API, and the only real prerequisite is that ten-second check of whether your PDF is text or a picture.