Pages and URLs
Language folders, page list, old-link migration, navigation, and breadcrumbs.
Multilingual websites
When the old site is beyond repair, build GEO and SEO into the new one.
Language versions follow target markets. Pages, localized content, SEO, speed, old URLs, and enquiries are designed together instead of adding translation after launch.
When a rebuild makes sense
Rebuilding is usually more efficient when a new business is launching, the company is entering another market, or routine updates keep breaking pages, languages, SEO, and forms.
Repair or rebuild
The question is not how old the site looks. It is whether the site still works.
A visual refresh may be enough. Rebuild when content, technology, and publishing remain unreliable.
| Current situation | Keep and repair | Rebuild |
|---|---|---|
| Pages and content | Core pages are clear and templates can change | Products, services, and languages remain mixed together |
| Technology and publishing | The system can produce stable pages and fix SEO and speed | Updates repeatedly break URLs, metadata, or mobile layouts |
| Languages | Each language can be edited and reviewed independently | Only raw machine translation is possible |
| Old URLs | Most URLs remain useful | Duplicate and invalid URLs block routine updates |
| Team maintenance | The team can publish, test, and roll back | Systems, permissions, or vendors make maintenance unreliable |
Content first
Explain the business before designing the pages
Inventory products, services, industries, use cases, and available material before deciding which pages the site needs.
- Every page has a clear purpose.
- The first screen explains the offer, buyer, and next step.
- Products, cases, FAQs, and guides connect naturally.
- Each language is rewritten for its target market and search behavior, not published from raw machine translation.
What is included
A complete multilingual website needs six things
Initial pages and languages follow the target markets, but every project checks these six areas.
Market-specific content
Target-market research, terminology, and localized home, service, case, guide, FAQ, about, and contact pages.
Facts and schema
Visible supporting facts with organization, service, article, FAQ, and breadcrumb data.
Mobile and desktop experience
One HTML system, clear structure, accessibility, responsive layout, and optimized images.
Enquiry forms
Form fields, source tracking, privacy, submission results, and secure lead access.
Launch and maintenance
Build, tests, caching, CDN refresh, monitoring, rollback, and maintenance notes.
Before launch
A page enters the production sitemap only after it passes
Content, technology, and visual behavior are checked in the same review.
- 01
Accurate content
Questions, answers, sources, and limits are reviewed.
- 02
SEO/GEO
Metadata, canonicals, languages, and schema agree.
- 03
Working interactions
Navigation, forms, errors, and no-script access work.
- 04
Good performance
Mobile speed, images, and caches meet the budget.
- 05
Launch checks
Origin, CDN, sitemap, and monitoring are verified.
Scope, timing, and pricing
Agree the website by phase instead of hiding unknown work in one total
These timings fit a company website when source material and reviewers are available. Product databases, accounts, or commerce need separate assessment.
Confirm pages, languages, and content first
Map the business, old URLs, source material, target markets, and enquiry path into a quotable scope.
Typically 6–12 weeks
Core content, responsive frontend, technical SEO, language rules, forms, tests, and launch are quoted by milestone.
12+ weeks or phased release
Large product sets, markets, migrations, CMS work, or integrations are split into accepted phases.
The quote lists pages, languages, content ownership, design and development limits, third-party costs, revision rounds, launch, and maintenance.
Related questions
About GEO-first multilingual websites
How is a GEO-first website different from a normal corporate website?
The difference is not visual style. From the start, the project defines which buyer questions to answer, which pages are needed, how important claims are supported, and how language versions are matched and tested.
Does it require a particular CMS?
No. Choose static delivery, a lightweight CMS, or an existing platform based on scale and roles. The requirement is stable crawlable HTML and consistent metadata.
Can we launch one language first?
Yes, but define future language folders, the default language, and counterpart rules before launch. Only completed language pages should appear in hreflang and the sitemap.
What happens to legacy content?
Inventory each URL and decide whether to keep, merge, rewrite, or remove it. Valuable old URLs redirect one-to-one to the most relevant new destination.
Planning a new website? Send the material you already have.
Products, target markets, and required languages are enough to start.