Denne integrasjonsveiledningen er kun tilgjengelig på engelsk.

BeMyWords with Tilda (and other hosted page builders)

A complete integration guide for Tilda, WordPress, and similar hosted CMSes (Wix, Webflow, Squarespace) where you can paste a <script> tag but can't run a build pipeline. Webshops count: Shopify and WooCommerce take the script in the theme's head the same way.

The whole setup is one step. Paste the script from your welcome email into the head of your site. The first time a visitor loads a page, BeMyWords creates the project for that site, reads your sitemap, learns any text the sitemap missed as visitors browse, translates it, and adds a language switcher once a language is ready. Nothing else has to be set.

Everything below that step is optional: pinning the script to one project, fixing a sentence on the page, choosing languages yourself.

Prerequisites

• A site on Tilda, WordPress, WooCommerce, Shopify, Wix, Webflow, Squarespace or any builder that lets you add a script tag to the head.
• A BeMyWords account. The welcome email carries your script.

1. Paste the script

The script in your welcome email looks like this:

<script src="https://www.bemywords.org/bw-editor/trigger.js"
        data-account="<your-account-token>"
        data-public-read="true"
        defer></script>

It finds the right project by the site it loads on, so one script serves every site in your workspace. If a site should always be one particular project, copy the project's own script from Connect in the app instead; it carries data-project-id in place of data-account, and everything else on this page is the same.

Paste this into the head of every page on your Tilda site. In Tilda, that's Site Settings → More → Insert HTML code to head. The same snippet works for every page — every string the site harvests lands in one shared namespace, so you don't need to set data-namespace.

The Connect page in the app shows a live install indicator that turns green within seconds once the script is loaded by any visitor.

Where the tag goes on WordPress

WordPress has no "paste into head" box, so pick whichever of these matches your setup — they all end up in the same place, wp_head:

• A headers plugin (WPCode, Insert Headers and Footers, or similar). Paste the snippet into the header field. This is the one to choose if you would rather not touch theme files, and it survives theme changes and updates.
• A child theme's functions.php, if you already have one:

  add_action( 'wp_head', function () {
      ?>
      <script src="https://www.bemywords.org/bw-editor/trigger.js"
              data-account="<your-account-token>"
              data-public-read="true"
              defer></script>
      <?php
  } );

• A classic theme's header.php, before </head> — but only in a child theme. Editing the parent theme's file works until the next theme update overwrites it.

Block themes (Twenty Twenty-Four and later) have no header.php to edit; use one of the first two.

Regional locales are handled for you. WordPress writes a regional tag into <html lang> — en-GB, nb-NO, de-DE — and the script reads that attribute. BeMyWords resolves a regional tag to its base language, so a nb-NO site is served the nb dictionary. Nothing to configure, and no need to change your site language.

2. Add a locale switcher

Drop this anywhere on the page where you want a language dropdown to appear:

<div data-bw-switcher></div>

The script will fill it with a <select> populated from the project's enabled languages. Picking a language stores the choice and reloads the page.

The chosen language is remembered in localStorage (not a cookie — nothing to declare in a cookie banner), so it carries across every page the visitor opens. Links don't need ?lang= appended; the script reads the stored preference on each load.

If you'd rather build your own switcher, just have it set the ?lang= query parameter — the script picks that up, applies it, and persists it. The resolution order is ?lang= → URL prefix (/en/, /nb-NO/) → stored preference → <html lang>. A ?lang= link stays shareable: opening it persists that language for the recipient's later navigation too.

Right-to-left languages

When the visitor's language is right-to-left (Arabic, Hebrew, Persian, Urdu, …), the script also sets dir="rtl" on <html>, so the whole page mirrors. Switching back to a left-to-right language restores the page's original direction. No extra setup is needed — note that absolutely-positioned Tilda blocks may need manual RTL tweaks in Tilda's editor, since dir only mirrors text flow and logical CSS.

3. Fix a sentence on the page (optional)

Open any page on your site and type the Konami code:

↑ ↑ ↓ ↓ ← → ← → B A

The editor opens in a panel on the right. It asks once for a personal access token, which you create in the app under your profile. Click any text on the page to find it in the panel, or double-click it to rewrite it there. What you save is the translation from then on.

The editor header also has ↺ Sync page strings, visible while the page shows its original language. It sends every string on that page at once, so you do not wait for a visitor to open it.

4. Choose languages yourself (optional)

Left alone, a language switches on by itself once enough visitors ask for it, and goes live when enough of it is translated. To decide yourself, open the project's Languages settings in the app and tick the languages you want translated. New strings in those languages are translated within seconds of arriving.

Changing an original sentence retranslates its AI drafts when Re-translate edited strings is on. Translations a person approved are never overwritten; they are flagged for review instead.

Nightly site sync

Every night at 02:00 UTC BeMyWords reads your sitemap again, picks up new pages and translates their text. The account script sets this up on its first load, so there is nothing to switch on. A project pinned with data-project-id gets it once you enter the site address on its Connect page.

5. How visitors see edits

The dictionary endpoint serves with ETag + must-revalidate. Every page load conditional-GETs the dictionary; the server returns 304 Not Modified (a few hundred bytes of headers) when nothing changed, and 200 with the new body when an edit landed. Visitors get edits on their next page load, with no CDN purge step.

API endpoints used with the script

If you're rolling your own client, these are the unauthed endpoints the trigger script uses:

And one authed endpoint used by the in-page editor's Sync button:

All rate-limited via rack-attack.

The script does not give you multilingual SEO

Read this before you install anything, because it decides whether the script is the right choice for you at all.

The script translates the page in the visitor's browser, at the same URL. There is no /fr/ or /de/ version of your page — there is one page, which looks different depending on who is reading it. The language is remembered in localStorage, not in the address.

The consequence:

• Your visitors get every language. Someone who lands on your site and switches to French reads French, on every page, and the choice follows them around the site.
• Google gets one language. With one URL there is one page to index, in your source language. No per-language URL means nothing for Google to rank in that language, and the script emits no hreflang — so a search in French will not find you.

If what you want is "my site is readable by my French customers", the script does exactly that and this guide is the right one.

If what you want is "my site is findable by French customers who have never heard of me", the script alone will not get you there. Your options:

• Use a build-time integration instead — Astro, Rails, Next.js and the rest write real translated files at real URLs, which is what ranks. This needs a build pipeline you control, which is exactly what Tilda and other hosted builders do not give you.
• Use your platform's own multilingual feature for the URLs, if it has one, and the script for everything it does not cover.
• Use a proxy-based service. Some competitors put a proxy in front of your site and serve translated HTML at /fr/. That earns them indexable URLs; it also means every visitor request goes through their infrastructure. We have deliberately not built that — see how we compare.

We would rather tell you this before you install than have you discover it in Search Console three months later.

Things that won't work with the script

• GitHub redeploy — not relevant; the dashboard hides the Redeploy tab automatically.
• CSV / file imports — those paths still work, but slug-shaped keys defeat the source-text-as-key convention. Avoid mixing modes on the same project.
• Pre-build language detection on the server — Tilda renders pages in the source language; the script swaps to the visitor's locale client-side. Visitors see a brief flash of the source language only on cold-cached first paint; warm cache + ETag revalidation makes subsequent loads instant.