ESDomain editorial team · Reviewed 2 November 2026
Start with the visitor’s task
A business serving Spain can receive enquiries from customers who prefer English. Decide what those visitors need to do before translating everything: understand a service, check a price or submit a request. List the pages that must exist in both languages so the person can complete that task without becoming stranded halfway through the journey.
A holiday rental, for example, might need the description, booking conditions and enquiry form in both languages. Translating the menu helps little if the next button opens information the customer cannot understand. Review confirmations, error messages and support instructions too. They remain part of the experience even though they are not the website’s front page.
Give each version a stable address
One possible structure is your-domain.es/es/servicios for Spanish and your-domain.es/en/services for English. These are planning examples, not paths created by purchasing a domain. Your builder or application must publish the pages. Predictable addresses make links easier to share and help your team verify which version a visitor is actually seeing.
The .es extension does not require every page to be written in Spanish. Agree the structure with the website team before distributing public links. Separate stable pages for each language make content reviews more straightforward and avoid an address changing its wording without giving the visitor an understandable way to choose the version they need.
Let customers choose their language
Provide a visible switch labelled Español and English, and check that it preserves the equivalent page where one exists. Someone reading terms should reach the translated terms when switching language. Always sending that person to the homepage adds work and can interrupt access to information needed before making a purchase or submitting an enquiry.
If you suggest a version based on country, keep each language URL directly accessible. Someone in Spain may prefer English, while someone abroad may need Spanish. Test links received through email without signing in. The initial suggestion and the means of changing it should be understandable, especially on pricing pages and customer forms.
Coordinate content and search signals
Give the developer a map of equivalent pages to check hreflang, canonical URLs and the sitemap. Do not label an unrelated page as a translation. When a product, condition or price changes in one language, review its counterpart too. Assign responsibility for that review so maintaining both versions does not depend on remembering isolated edits.
Write each version for its audience. Explain currency, timing and the information customers must provide in language they understand. Avoid repeated blocks of city names that add no useful detail. Language and the domain extension help present the project, while the value of each page still depends on the visitor’s question it actually answers.
Review a complete enquiry or purchase
Before launch, ask one person to complete the journey in Spanish and another in English. Have them find a particular page, switch language and send an agreed test enquiry. Record where they hesitate and correct wording or links that make the next step unclear. Include phone-width screens when reviewing important forms and buttons.
If you have not chosen an address, check the .es name and prepare accurate holder information. Connect your chosen host and publish both versions after registration. Translation alone does not guarantee visits or rankings. Keep the page map and review customer questions to decide which content needs clearer explanations as the business starts receiving enquiries.