Translate your archive in bulk
Most non-English search markets are dramatically under-served by English-language creators — the competition for the same topic in Spanish, Portuguese, German, or Japanese is often a fraction of what it is in English. Translating a proven, already-ranking English archive is one of the highest-ROI moves in international SEO. The reason almost nobody does it is cost and logistics: a translation agency charges ten to twenty cents a word, so a 200-post blog runs five figures, and then you still need someone to publish each translation and manage a sister site. An assistant translates that same archive for roughly the price of a nice dinner, and Specter handles the publication — write the translated markdown files, push them as drafts to your sister CMS, review, publish.
What you need
- Specter synced to your primary site, and configured for a second target-language CMS (two configs, switch with a flag)
- An AI assistant you already use
- Optional: a native speaker to spot-check the first twenty
The recipe
- Pull the source archive. Run a Specter pull on your primary-language site.
- Scope it. Don’t translate thin content — run the thin content auditor first and queue only the posts worth keeping, or just your top Search Console pages.
- Translate. Run the prompt below; it writes translated files to a parallel folder.
- Spot-check, then publish. Read twenty random files (with a native speaker if you can), point Specter at the sister CMS, dry-run to confirm clean creates with no slug collisions, and push as drafts.
- Set hreflang. Link each translation to its original with
hreflangtags — a one-time theme change, done before you publish.
The prompt
You are translating a blog archive into the target language. For each queued slug,
read the source post and translate the title, meta description, excerpt, body
(preserving all markdown structure), and tag labels. Do NOT translate URLs in
links, code blocks, brand and product names, or frontmatter field names — only
values. Write to a parallel folder with frontmatter: translated title, a
language-natural slug, status: draft (never published), a lang code, and an
original_slug field for hreflang mapping. Match the source's voice and register —
use natural idiom over literal translation, and swap metaphors that don't carry
for local equivalents. Checkpoint progress every 10 files.Cost and time
| Blog size | Tokens | Cost | Wall-clock (translation only) |
|---|---|---|---|
| 50 posts | ~2M | $5 | 30 min |
| 200 posts | ~8M | $20 | 2 hr |
| 600 posts | ~24M | $60 | 6 hr |
Add five to ten minutes of review per translated post that actually publishes.
Pitfalls
- Machine translation can feel machine. Plan to polish tone on each post that goes live — which is exactly why the rule is drafts only.
- Hreflang is non-optional. Without it, Google may treat your language versions as duplicates and index neither. Set the tags up before publishing.
- Localize currencies, dates, units, and idiom. “Get the ball rolling” shouldn’t be translated word-for-word — catch these in review.
Where to go next
Even at the high end this is roughly a hundred times cheaper than agency rates. Run the internal link engine over the translated archive afterward to build internal authority in the new language, and if you generate image alt text, do it per language with the excerpt and alt-text sweep.