How to Build a Multilingual IDX Site on WordPress

Last updated: June 14, 2026

By Alex Torres, MLSImport integration consultant with experience deploying bilingual WordPress IDX sites for Canadian and US brokerages.

Your Spanish- or French-speaking buyers are searching right now, and if your IDX site only speaks English they are landing on a competitor’s. A multilingual IDX WordPress site fixes that, but it comes down to one architectural choice you cannot reverse later: you need organic IDX that stores listings as native WordPress posts, not a hosted IDX that locks the data on a vendor’s servers. Get that right and the rest falls into place. From there you pick one of three workflows: translate your top listings by hand, run a full bilingual catalog, or auto-translate the whole site at scale. The result is clean /en/, /fr/, and /es/ language-folder URLs with their own slugs and sitemaps, giving overseas buyers long-tail organic visibility in their own language. Here is how.

The teams that pull this off, Canadian brokerages running full English/French catalogs and US offices serving Spanish-speaking and overseas investors, all lean on the same playbook: organic IDX for the data, WPML real estate listings or Polylang for the language layer, and a bilingual real estate website WordPress setup that never touches the raw MLS feed.

Hosted IDX vs. Organic IDX: Why Architecture Decides Multilingual Capability

Hosted IDX, the widgets, iframes, and scripts that keep listings on the vendor’s servers, cannot produce real multilingual pages. Organic IDX, which imports listings into your WordPress database as native posts, can.

Hosted services like IDX Broker and iHomefinder keep listing pages and search on their own infrastructure, then embed them through frames or scripts. That usually means one English interface, fixed vendor URL patterns, and overlay translations that search engines mostly ignore. Showcase IDX renders HTML on your domain but stores the data in a separate system, so you cannot apply WordPress taxonomies or custom fields to the raw records. Organic IDX that stores listings locally brings better global SEO and language control than hosted widgets. For a site targeting overseas or bilingual buyers, that architectural difference is the deciding factor.

MLSImport imports MLS data through the RESO Web API into WordPress as native posts, taxonomies, and custom fields. Because each property is real WordPress content, the standard translation plugins can build genuine per-language pages with their own slugs, titles, meta descriptions, and schema. Realtyna also stores data locally and can be wired into WPML, though it typically needs more setup and tuning to reach the same comfort level. None of this makes hosted IDX a bad choice for an English-only site. The gap only opens once you care about multilingual reach and international search visibility.

What hosted IDX gives you, and what it doesn’t

Hosted IDX hands you a working search and listing pages quickly, but the multilingual limits are structural, not cosmetic. You get fixed vendor URL patterns such as /listing/123456, with no control over the slug. Search forms render from the vendor’s servers, so you cannot translate them at the WordPress level. Overlay translation repaints what the visitor sees without producing a separate, indexable language URL, and you have no control over taxonomy slugs, meta tags, or schema on those pages.

How organic IDX unlocks real per-language pages

Because organic IDX stores listings as native WordPress posts with custom fields and taxonomies, the entire WordPress plugin ecosystem becomes available, including WPML, Polylang, and Weglot. You can set custom permalink structures like /es/casas-de-lujo/ and /fr/maisons-de-luxe/, write language-specific meta titles, and generate a separate sitemap per language. One feed from the RESO Web API powers every language version, so there are no duplicate imports and all versions stay in sync. The translation-ready themes, WPResidence, Houzez, RealHomes, and WP Estate, ship .po and .mo language files, so the fixed labels are handled before you translate a single listing.

The Core Rule: Translate the Shell, Not the MLS Data

Translate every part of your WordPress site you control, the labels, menus, search forms, taxonomies, and your own content blocks, but never modify the raw MLS remarks, legal text, or field values that MLSImport imports directly from the board. Getting this backward is the most common mistake bilingual real estate sites make.

“The shell” means the parts that belong to WordPress and your theme: labels like Price and Precio, Bedrooms and Dormitorios, Search and Buscar; navigation menus; search form field names; taxonomy term names such as Property Type and Type de propriété; your own custom content blocks; meta descriptions; and page titles. “The MLS data” means the remarks and property description supplied by the agent and board exactly as submitted, the status strings (Active, Pending, Sold), and the disclaimer and attribution lines. The principle is simple: translate the shell, not the raw listing data. MLSImport never machine-translates the feed, because a single altered word in a remark or disclaimer can put you offside with the board.

In practice, this split also protects your time. Field mapping during setup takes roughly 30 to 60 minutes. Once those fields are mapped, MLS data syncs hourly, and the translated labels you set once, whether in a .po file or through a translation plugin, survive every sync cycle untouched. You translate the interface once; the board’s text keeps flowing in exactly as sent.

WPML, Polylang, and Weglot: Which Plugin Fits Which Use Case

WPML and Polylang give you editorial control over individual property translations and suit curated catalogs of up to a few hundred listings. Weglot auto-translates the entire rendered site and fits inventories in the thousands.

WPML duplicates and links posts per language, so you translate titles, excerpts, slugs, and descriptions listing by listing. It shines on roughly 50 to 200 high-value properties where editorial quality matters, and because translation-ready themes ship .po and .mo files for the fixed labels, WPML only handles the variable listing content. Polylang takes a similar approach: language-specific URLs for archives and single properties using the same underlying posts, with per-language taxonomy terms mapped together. It suits smaller bilingual sites managing a few dozen up to roughly 200 key listings.

Weglot works differently. It reads the rendered HTML and auto-translates the whole front end without duplicating posts in the database, and the first translations go live within minutes. That makes it the natural fit for thousands of fast-changing listings: overseas investor portals, large US Spanish-speaking markets, and any catalog too big to translate by hand. Underneath all three, theme string translation through .po and .mo files handles the fixed labels, buttons, and menus once, unaffected by the hourly MLS sync, no matter which plugin you choose.

📌 Pro Tip: For a first bilingual setup, start with WPML or Polylang on a small set of your best listings. You will learn how translations behave against the hourly sync before you ever commit to auto-translating the whole catalog with Weglot.

How Do Imported Fields, Taxonomies, and Search Forms Get Translated?

MLSImport syncs price, status, photos, and core MLS fields hourly, and those stay in the source language. Theme labels, taxonomy term names, and search form strings are separate WordPress elements you translate once, and they survive every sync.

What syncs every hour is the data the board owns: price, status, beds and baths, square footage, photos, and the MLS remarks. Everything around that data lives in WordPress and is never touched by a sync. MLSImport also keeps the MLS listing ID on every post, so translated pages at /es/ or /fr/ inherit those identifiers and leads tie back to the correct listing. Spanish characters and any Unicode text are stored exactly as the feed sends them, with no corruption. Custom taxonomies like “Chinese-speaking commuters” or “Kosher-friendly neighborhoods” sit alongside the MLS data without touching it, fully translatable at the WordPress taxonomy layer.

Theme UI strings and fixed labels

Themes such as WPResidence, Houzez, RealHomes, and WP Estate ship .po and .mo language files covering labels like Price and Precio, Bedrooms and Dormitorios, Property Type, and Buscar. You translate these strings once, either directly in the .po file or through WPML’s String Translation module, and they survive every hourly sync because they live in theme code, not in post meta. Concretely: the Buscar button stays in Spanish even after a listing’s price updates overnight, because the sync touched the price field, not the button label.

Property taxonomies and archive pages

When WPML or Polylang links taxonomy terms across languages, archive pages get language-specific slugs. A property-type archive becomes /es/tipo-de-propiedad/apartamento/ in Spanish and /en/property-type/apartment/ in English, both drawing from the same imported taxonomy values that MLSImport mapped in. Weglot reaches the same end result through a different route: it handles the translation at render time, so it does not need duplicate taxonomy terms in the database.

Three Multilingual Workflows for Live MLS Feeds

The right workflow depends on inventory size, team capacity, and market requirements: translate only your top 20 to 50 listings by hand, maintain a full bilingual catalog, or let Weglot auto-translate the entire site overnight. One rule of thumb unifies all three.

The rule: manually translate fewer than 5% of your properties, and let plugins or the source language cover the rest. Above that ceiling, the hourly sync makes hand translation unsustainable. The manual count you will hear quoted varies, roughly the top 20 to 50 per city, sometimes 50 to 100 or up to 200. Treat it as a range rather than an absolute, with the under-5% rule as the boundary that keeps human effort sane.

📌 Pro Tip: Before you decide which listings deserve a human translation, watch 30 days of analytics. Let real traffic, not a guess, tell you which cities and languages are actually pulling buyers in.

Workflow 1, Base + selective: translate your top listings only

Here the MLS language, usually English, stays as the base, and your team manually translates only the highest-value listings in WPML or Polylang: titles, excerpts, and agent-written description blocks. The theme interface is fully translated through .po and .mo files, so every visitor gets a native search experience. This fits a US broker serving a mainly English-speaking market with a meaningful but minority Spanish-speaking clientele. Keep one eye on the under-5% ceiling. Push past it and the hourly sync turns manual translation into a job nobody can keep up with. In practice, the teams that stall are the ones that try to hand-translate the whole catalog instead of holding to that ceiling.

Get started: open your top 20 listings in WPML or Polylang and translate just the titles and excerpts first. That alone gives bilingual buyers a native entry point.

Workflow 2, Full bilingual catalog: every listing in two languages

In this model, every imported property has a linked second-language version created by WPML or Polylang. Translators work on titles, excerpts, and any agent-rewritten content blocks, while price, status, and core MLS fields sync hourly and need no translation effort. When a listing goes sold or off-market, MLSImport removes or updates all language versions at once, so no stray translated page advertises a home that is gone. This is the Canadian English/French pattern, where both official languages must be supported across the entire catalog. A large, fast-changing feed makes this workflow labor-intensive, which is exactly why the under-5% rule exists and why Workflow 3 does too.

Get started: map your translator workflow to the .po and .mo theme labels first, then let WPML or Polylang link each new import to its second-language version as it arrives.

Workflow 3, Auto-translate at scale with Weglot

Weglot auto-translates the rendered HTML of the entire site, listing archives, single-property pages, and search results, without duplicating posts in the WordPress database. A working bilingual or multilingual site can be live within a day. This fits US English/Spanish markets with large inventories of 2,000 to 10,000 or more listings, overseas investor portals serving Chinese, European, or Middle Eastern buyers, and any case where translating thousands of rapidly changing properties by hand is impractical. A few caveats: per-page-view translation adds load, though Weglot offloads it to its own servers; page caching matters at scale; and machine translation quality varies, so any compliance-flagged content should be checked. The MLS remarks and disclaimers stay untouched here too, no matter the workflow.

Get started: connect Weglot to a staging copy, add your target languages, and check page-cache behavior before pointing it at your full live inventory.

Localizing Listings for International and Bilingual Buyers

Language translation gets buyers to your site. Localization, the currency context, measurement conversions, cultural content blocks, and segment-specific landing pages, keeps them engaged long enough to become a qualified lead. The strength of organic IDX is that all of this content sits alongside the MLS data without ever touching it.

Currency hints and dual measurement units

Two touches do most of the work. First, a currency context badge near the price field: “$3.7M USD / ~€3.4M estimate.” This is not a live converter feeding off a bank API, just a context hint or a lightweight widget showing approximate equivalents in GBP, EUR, or CAD beside the MLS price. Second, a dual measurement display: “4,000 sq ft (approx. 372 sq m),” added as a secondary value in the theme’s property detail template, often paired with a square-meter calculator for buyers who do not think in square feet. Both sit next to the MLS price and size fields. Neither alters the raw MLS data, which is what keeps the page compliant.

Cultural content blocks, custom taxonomies, and lead routing

Beyond numbers, overseas buyers often want process help more than another property detail. You can place custom content blocks above or below the listing template: neighborhood guides, “How to buy from overseas,” “Taxes for non-resident owners,” and “How closing works in Florida for EU buyers,” worth triggering especially for listings above roughly $2M. Custom taxonomies sit beside the MLS data without touching it: “Chinese-speaking commuters,” “Kosher-friendly neighborhoods,” “Short walk to PATH.” They power filtered landing pages segmented by commute time, school district, price band, or cultural affinity. Lead routing ties it together: with the MLS ID passed through hidden fields, a Spanish- or French-speaking buyer’s inquiry arrives at your CRM already matched to the exact listing, so it routes to the right agent with no manual cross-referencing.

How Does MLS Compliance Work on Multilingual Pages?

Most MLS boards permit multilingual pages. What they require is that disclaimer text, attribution lines, and data timestamps appear exactly as mandated on every page, regardless of the surrounding language. Translating your site does not create compliance risk on its own; editing the board’s data or its legal text does.

Boards care about two things: data integrity, meaning you do not modify field values from the feed, and visible credit, meaning the disclaimer text, logo, and attribution line appear exactly as required. In the NYC commuter belt, REBNY RLS, NJMLS, and GSMLS each expect their disclaimer and logo placed into your theme templates with the wording untouched, even on a Spanish or Chinese page. You control the layout; you just do not get to reword the legal line.

What you can add is helpful here. You are free to place one or two translated explanatory lines above or below the official disclaimer, for example a short note in Spanish or Chinese explaining that the data comes from the MLS, as long as the legal line itself is reproduced exactly and stays clearly visible. Because the RESO Web API uses shared field names across more than 800 North American MLSs, with 20 to 30 core fields aligning across most markets, one field-mapping setup can serve a multi-market, multi-language site without rebuilding your search logic. MLSImport never rewrites that MLS text inside the feed, because the feed has to match what the board sends, word for word.

📌 Pro Tip: My recommendation: email your board’s compliance contact before placing any translated text near an official disclaimer, and confirm the layout is acceptable. Five minutes of outreach now beats a takedown notice later.

Language-Folder URL Architecture and International SEO

Organizing a multilingual IDX site into /en/, /fr/, and /es/ language subfolders, each with its own sitemap, gives Google distinct, indexable pages per language and generates long-tail organic traffic from overseas buyers searching in their own language.

With the language-folder structure, each language gets separate archive and single-property URLs with custom slugs, titles, meta descriptions, and schema. The source examples make the pattern concrete: /en/luxury-homes/ versus /es/casas-de-lujo/, /en/invest/miami-condos/, and /zh/invest/toronto-presales/. One RESO feed powers all of these language versions, so there is no double entry and every version stays in sync. Language-specific sitemaps then let Google rank your /en/, /fr/, and /es/ pages separately across countries, turning a deep catalog into a long tail of pages overseas buyers actually find.

The scale advantage is direct. A hosted setup gives search engines a vendor-URL structure attributed to the vendor, not to you, while organic IDX gives you hundreds or thousands of indexable pages on your own domain. MLSImport creates SEO-friendly property URLs you control: permalinks, titles, and meta descriptions. A subdomain such as es.example.com is another option WPML supports, but a subfolder like /es/ is generally preferred because it consolidates domain authority rather than splitting it.

Performance and Scaling a Multilingual MLS Site

A WordPress site with 5,000 to 20,000 imported MLS listings across two or three languages is manageable with good hosting and caching. Adding languages multiplies your page count, but it does not multiply RESO API calls, because all language versions share one feed.

At 2,000, 5,000, 10,000, or 20,000 and more imported posts, the listings are still simple WordPress posts that the database can index given appropriate hosting. Adding one or two languages does not double the MLS calls, since the same single RESO feed serves every language version. What you do need is page caching, database indexing, and optionally object caching. Auto-translating a large inventory through Weglot adds per-page-view processing, but Weglot offloads that to its own servers, so caching on your side keeps archive and search pages fast. In practice, at ten thousand-plus listings the bottleneck is rarely the import itself, it is uncached archive pages and heavy image galleries, which is why caching and the external image CDN matter.

Photos are the other performance lever. MLSImport pulls full photo sets from high-speed external storage, so 40 to 50 high-resolution images per listing do not crush your hosting, which also helps visitors loading galleries over long-distance connections. One constraint stays firm: a single MLSImport instance supports one RESO feed. For multi-MLS coverage, such as REBNY RLS for New York City plus NJMLS for the New Jersey suburbs, you run a separate WordPress site per feed and cross-link them with consistent navigation and branding.

Key Takeaways

1. Organic IDX (MLSImport) imports MLS listings as native WordPress posts, giving WPML, Polylang, and Weglot full access to per-language URLs, slugs, and taxonomy archives.
2. The core rule of a multilingual IDX WordPress build: translate the shell (labels, menus, search forms, your own content) and never alter the raw MLS data or board legal text.
3. Translate fewer than 5% of inventory manually, roughly the top 20 to 50 listings per city, and let plugins or the source language handle the rest.
4. MLS disclaimer text, attribution lines, and board logos must appear exactly as required on every language version; boards like REBNY, NJMLS, and GSMLS enforce this regardless of language.
5. One MLSImport instance supports one RESO MLS feed; for multi-board coverage like NYC plus the NJ commuter belt, run separate WordPress sites and cross-link them.

Frequently Asked Questions

Does MLSImport automatically translate MLS listing descriptions into other languages?

No. MLSImport imports MLS remarks and all field data exactly as the board sends them, with no machine translation applied to the feed at any point. Translating the raw property description would risk altering a legal field and could breach MLS data rules. Instead, you translate the surrounding WordPress layer: theme labels, menus, search forms, and any custom content blocks you write. The listing description itself stays in the MLS language throughout.

Does MLSImport include a built-in language switcher?

No. MLSImport focuses exclusively on importing and syncing MLS data; it does not bundle a language module or switcher. You add language switching by installing WPML, Polylang, or Weglot alongside the plugin. These tools place a language switcher in your theme header or widget areas and handle per-language URL routing. The separation is deliberate, since it lets you choose the translation tool that fits your catalog size, team capacity, and budget.

Will hourly sync overwrite or break my translated pages?

No. MLSImport’s hourly sync updates core MLS fields, price, status, beds and baths, photos, and remarks, within the existing WordPress post record. Translated titles, slugs, and content added through WPML or Polylang live in separate database entries that the sync never touches. Theme labels and .po/.mo string translations are also unaffected. If a listing goes off-market, the plugin removes or updates all language versions simultaneously, so no stray translated page lingers.

WPML vs. Polylang vs. Weglot, which should I use?

Choose WPML or Polylang for editorial control over a curated catalog of roughly 50 to 200 high-value listings; both let you translate titles, slugs, and excerpts property by property. Choose Weglot for large or fast-changing inventories of thousands of listings, since it auto-translates the rendered site without duplicating posts and a working bilingual site can be live within a day. Canadian English/French markets requiring full catalog coverage typically use WPML or Polylang with MLSImport.

Can one MLSImport site serve multiple languages with clean, SEO-friendly URLs?

Yes. Paired with WPML or Polylang, an MLSImport site produces clean /en/, /fr/, and /es/ language-subfolder URLs with custom slugs, per-language meta titles, and separate sitemaps. Google indexes each language version independently, generating long-tail organic traffic from overseas and bilingual searches. Weglot achieves similar URL structures through its own routing layer. All language versions draw from the same single RESO feed, so no duplicate imports are needed.

Do translated pages still tie Spanish- or French-language leads to the correct MLS listing?

Yes. MLSImport stores the MLS listing ID and reference fields on every WordPress post, and translated listing pages at /es/ or /fr/ inherit those identifiers. Lead forms embedded in translated templates pass the MLS ID through a hidden field, so when a Spanish-speaking buyer submits an inquiry the CRM or email notification identifies the exact listing and routes the lead to the appropriate agent team. No manual cross-referencing is required.

Can it handle RTL languages and non-Latin scripts like Arabic, Chinese, or Hebrew?

MLSImport stores any character, accent, or Unicode text exactly as the MLS feed provides it. Support for right-to-left layout and non-Latin scripts, Arabic, Hebrew, and Chinese, depends on the WordPress theme. Translation-ready themes such as WPResidence, Houzez, and RealHomes support RTL layouts when a compatible RTL stylesheet is active and a translation plugin routes the correct language direction. Pair the plugin with a theme that explicitly lists RTL support to serve these audiences reliably.

Can I target multiple MLS markets, for example NYC and the NJ commuter belt, from one site?

Not from a single MLSImport instance, since one instance supports one RESO MLS feed at a time. For multi-board coverage such as REBNY RLS in New York City alongside NJMLS or GSMLS in New Jersey, you run a separate WordPress site for each MLS feed and cross-link them with consistent branding and shared navigation. A commuter-focused portal, for example, can present NYC listings on one domain and NJ listings on a second, linked prominently.

Bringing It All Together

The sequence matters more than any single tool. Start with organic IDX so your listings live in your own WordPress database, then pick the language layer that fits your catalog: WPML or Polylang for a few hundred curated listings, Weglot for thousands. Translate the shell around the data, never the MLS feed itself, and keep every board disclaimer exact on every language version.

Do that and a bilingual site stops being a compliance worry and becomes a steady source of overseas, long-tail traffic. Built a bilingual site with MLSImport, or stuck somewhere mid-setup? Tell us what you ran into in the comments.