The Italian alternate pointed to English. How we fixed Wix Multilingual
The Italian version of the NourVerse projects page opened at the correct address. In the published HTML, the hreflang link for Italian pointed to the English page. A visitor using the language switcher could see the right content while a search crawler received a conflicting signal. Here is how we found the difference and what we checked after fixing it.
Start on an inside page
Open Projects and record its full address. Switch to Italian and check the heading, content and address. On NourVerse, the pair was /portfolio for English and /it-it/portfolio for Italian. Open both addresses in a private window as well. That gives you a first-visit check without a previously saved language preference.
Repeat the trip on a page where a visitor can act, such as Contact. Switch languages from that page and check that you can still reach the same task. Read the labels, required-field errors and submit button in the selected language.
Check canonical and hreflang together
In the published HTML, find rel="canonical" and the links with hreflang. Our Italian page already had /it-it/portfolio as its canonical. The it-IT alternate still pointed to /portfolio. Put the expected and observed destinations next to each other. Check the alternate links on each version so the pages identify one another consistently.
The primary English locale and the Italian locale both used the it-IT regional format. We configured en-IT for English and retained it-IT for Italian. On all four published Projects versions, it-IT then pointed to /it-it/portfolio and en-IT to /portfolio. This was the cause on our Wix setup. For another site, start with the exact links your CMS produces before changing a setting.
Try the switcher around layout changes
We checked the menu in the browser at widths including 337, 899 and 1,348 pixels. At 899 pixels we switched from Italian to Arabic and opened the menu. At 337 pixels the Arabic Contact form displayed right-to-left fields without horizontal page scrolling. Test a width on either side of each layout change to catch a language selector sitting on top of the menu.
Use the keyboard as well. Tab to the switcher, press Enter to open it and look for visible focus as you navigate. In Arabic, try a field containing digits and an email address. On a real phone, also test the on-screen keyboard and landscape orientation. Record device results separately from browser viewport results.
Keep a check you can repeat
For each test row, capture the starting page, selected language, expected address, observed address, canonical and outcome. A visible switcher problem points you toward its destination. If the correct URL and text load but an alternate still points elsewhere, inspect the CMS-generated metadata. Repeat the same row after changing the relevant setting.
Start with four rows for Projects, one per language. Then add routes that matter to visitors, such as Contact, a download or a booking. Your check passes when each page opens directly, the switcher leads to the same page and its published metadata identifies the expected language URL.
Comments