Building an English Website for Your Japanese Business in 2026
Your first international customer lands on your English homepage from San Francisco. The currency toggle breaks because your Japanese payment gateway doesn't recognize USD routing. The contact form rejects their input because you're still validating against kanji character sets. Your CTA button reads 'Send' but fires a 403 error on non-Japanese IPs. This is what happens when you treat English expansion as a translation project instead of an architecture problem. Japanese companies going global face 127 technical forks before a single word gets translated — character encoding that handles both UTF-8 and Shift_JIS, payment providers that clear internationally, CDN routing that doesn't penalize US visitors with 800ms Tokyo round-trips, and SEO scaffolding that doesn't cannibalize your .jp domain authority. Bolt these on after launch and you're replatforming in six months. But sequence them correctly and your English site becomes the revenue channel your shareholders expected.
This guide covers what you need to know in 2026, with specific technical recommendations, real cost data, and framework comparisons.
Table of Contents
- Why Japanese Businesses Need a Purpose-Built English Website
- Architecture Decisions: Subdomain, Subdirectory, or Separate Domain
- Choosing the Right Tech Stack in 2026
- Headless CMS Selection for Bilingual Content
- Internationalization (i18n) Implementation
- Design and UX Considerations for Western Audiences
- International SEO Strategy
- Performance Optimization for Global Delivery
- Legal, Compliance, and Payment Considerations
- Cost Breakdown and Timeline
- FAQ
Why Japanese Businesses Need a Purpose-Built English Website
Here's what we see constantly: a Japanese company slaps a Google Translate widget on their .co.jp site and calls it their "English version." It tanks. SEO, user experience, conversion rate, brand perception — all of it falls off a cliff.
The data backs this up pretty decisively. CSA Research's 2025 survey found that 76% of online consumers prefer to buy products with information in their native language, and 40% will never purchase from websites in other languages. So if you're a Japanese business targeting the US, UK, Australia, or English-speaking Southeast Asia? A dedicated English web presence isn't a nice-to-have. It's table stakes.
And then there's the design problem. Honestly, this one's harder to crack than the language stuff. Japanese web design conventions are just fundamentally different from what Western users expect. Japanese sites tend to feature:
- Dense text layouts with minimal whitespace
- Heavy use of banner images with embedded text
- Detailed product specifications front and center
- Multiple navigation paths and information-heavy homepages
Western users want clean layouts, clear visual hierarchy, prominent CTAs, and fast load times. That's not a stereotype — it's what the heatmap data shows, project after project. A purpose-built English site lets you serve both audiences authentically without compromising either one.
Architecture Decisions: Subdomain, Subdirectory, or Separate Domain
This is your first real technical decision, and it's got major SEO and operational implications. Don't treat it as an afterthought.
| Approach | Example | SEO Impact | Maintenance | Best For |
|---|---|---|---|---|
| Subdirectory | company.co.jp/en/ |
Inherits domain authority | Single codebase | Companies with strong existing domain |
| Subdomain | en.company.co.jp |
Treated as separate site by Google | Separate deployment possible | Companies wanting independent operations |
| Separate domain | company.com |
Builds fresh authority | Fully independent | Serious international expansion |
| ccTLD per market | company.co.uk, company.com.au |
Strongest geo-targeting | Highest maintenance | Multi-market enterprises |
Our Recommendation for 2026
For most Japanese SMBs and mid-market companies, go with a subdirectory approach (company.co.jp/en/) if your existing domain has solid authority (DA 40+), or a separate .com domain if you're building a distinct international brand.
Google's John Mueller has said repeatedly that subdirectories inherit domain authority, which makes them efficient for SEO. That said, a separate .com gives you full control over hosting location, tech stack, and content strategy — and that matters a lot when your Japanese site runs on some legacy WordPress install with a Japanese-specific theme that's basically impossible to extend. We've inherited enough of those projects to know the pain firsthand.
Already on a modern headless architecture? Then the subdirectory approach with locale-based routing is technically clean and maintainable. Next.js and Astro both handle this natively.
Choosing the Right Tech Stack in 2026
Your tech stack touches everything: performance, developer experience, content management workflow, long-term maintenance costs. Here's how the leading options compare for bilingual Japanese-English sites:
| Framework | i18n Support | Performance (LCP) | Learning Curve | Best For |
|---|---|---|---|---|
| Next.js 15 | Built-in i18n routing | ~1.2s (static), ~2.1s (SSR) | Moderate | Full-featured web apps, e-commerce |
| Astro 5 | Plugin-based (astro-i18n) | ~0.8s (static) | Low-Moderate | Content-heavy sites, marketing sites |
| Remix/React Router 7 | Manual implementation | ~1.5s (SSR) | Moderate-High | Complex interactive applications |
| Traditional WordPress | WPML/Polylang plugins | ~3.2s (typical) | Low | Budget-conscious, simple sites |
| Headless WordPress + Next.js | Framework-level | ~1.3s | High | Content teams familiar with WP |
Next.js for International Business Sites
Next.js 15's App Router gives you first-class internationalization support through middleware and parallel route segments. Here's a basic locale layout structure:
// app/[locale]/layout.tsx
import { notFound } from 'next/navigation';
const locales = ['en', 'ja'];
export default function LocaleLayout({
children,
params: { locale }
}: {
children: React.ReactNode;
params: { locale: string };
}) {
if (!locales.includes(locale)) notFound();
return (
<html lang={locale}>
<body>{children}</body>
</html>
);
}
This gives you /en/about and /ja/about with shared components but locale-specific content. Our Next.js development team has built dozens of bilingual sites using this pattern — it scales well to 5+ languages when clients eventually decide to expand further. And they always do.
Astro for Content-First Sites
If your English site is primarily marketing and content — corporate profile, product catalog, blog — Astro 5 delivers performance that's genuinely hard to beat. Its island architecture means zero JavaScript ships to the client unless you explicitly opt in. That's massive for Core Web Vitals.
For a Japanese manufacturer's English product catalog, we've seen Astro sites hit sub-second LCP globally with static generation. That kind of speed matters when your target audience spans San Francisco to London to Singapore. Check out our Astro development capabilities for specifics.
Headless CMS Selection for Bilingual Content
Managing content in Japanese and English requires a CMS with solid localization features. Not all headless CMS platforms handle CJK (Chinese-Japanese-Korean) characters well — and content modeling for bilingual sites has specific gotchas that'll bite you if you're not paying attention.
| CMS | Japanese Support | Localization Model | Pricing (2026) | API Performance |
|---|---|---|---|---|
| Contentful | Excellent | Locale-per-field | From $300/mo (Team) | Fast, global CDN |
| Sanity | Excellent | Document-level or field-level | From $0 (Free tier) to $199/mo+ | Fast, customizable |
| Storyblok | Good | Field-level with visual editor | From €109/mo | Good, EU-hosted default |
| Hygraph | Good | Locale-per-field | From $0 (Free) to $299/mo+ | Fast, EU/US regions |
| microCMS | Native Japanese | Built-in i18n | From ¥4,900/mo (~$33) | Fast, Japan-hosted |
| Newt | Native Japanese | Multi-locale support | From ¥0 (Free) to ¥4,980/mo | Good, Japan-hosted |
The microCMS and Newt Advantage
For Japanese companies, microCMS and Newt deserve a serious look. Both are Japanese-built headless CMS platforms with native Japanese interfaces, Japanese-speaking support teams, and data hosting in Japan. Why does that matter? Way more than you'd think:
- Your Japanese content team works in an interface they actually understand — no fumbling through English admin panels or second-guessing menu labels
- Support operates on Japanese business hours, in Japanese
- Compliance with Japan's APPI (Act on Protection of Personal Information) is baked in
- API response times from Japan-based servers are excellent for your Japanese site
The trade-off is obvious: international API response times can lag behind globally distributed alternatives like Contentful or Sanity. But here's the thing — this is entirely solvable with static generation (ISR or full SSG), which eliminates runtime API calls for end users. Problem solved.
Our headless CMS development practice can help you figure out which CMS actually fits your team's workflow and technical requirements.
Internationalization (i18n) Implementation
Content Translation Workflow
Emailing spreadsheets to translation agencies is dead. Good riddance. Modern bilingual site workflows look like this:
- Content authored in Japanese in the CMS by your team
- Translation triggered via CMS webhook to a translation management system (TMS)
- Professional translation completed (human or human-reviewed AI)
- Translated content pushed back to the CMS English locale via API
- Preview and approval by an English-speaking team member
- Publish triggers a rebuild/revalidation of the English site
Tools like Phrase (formerly Memsource), Crowdin, and Lokalise integrate directly with Contentful, Sanity, and other headless CMS platforms. In 2026, AI-assisted translation with human review has become the standard — it cuts translation costs 40-60% versus fully manual workflows while maintaining quality that's actually publishable.
Translation Cost Benchmarks (2026)
| Method | Cost per Word (JA→EN) | Quality | Turnaround |
|---|---|---|---|
| Professional human translation | $0.12–$0.20 | Highest | 2-5 days per 1,000 words |
| AI + human review (MTPE) | $0.05–$0.10 | High | 1-2 days per 1,000 words |
| AI-only (GPT-4o, Claude, DeepL) | $0.001–$0.005 | Good (variable) | Minutes |
| In-house bilingual staff | Salary cost | Variable | Depends on capacity |
For marketing copy and brand messaging, invest in professional human translation. This is non-negotiable. For product descriptions, technical docs, and blog content, AI + human review (machine translation post-editing, or MTPE) gives you the best cost-to-quality ratio by far.
Handling Japanese-Specific Content Challenges
Japanese-to-English localization has technical quirks that catch teams off guard:
- Text expansion: Japanese text is typically 20-30% shorter than equivalent English. Your UI components need to handle longer English strings — buttons that looked fine in Japanese suddenly overflow. Every. Single. Time.
- Date formats: Japanese uses 2026年1月15日; English expects January 15, 2026 or 15/01/2026 (UK)
- Number formatting: Japanese uses 万 (10,000) as a base unit; English doesn't have an equivalent
- Tone and register: Japanese business language is highly formal; English business copy tends toward conversational authority
- Line breaking: Japanese text has no spaces between words, requiring different
word-breakCSS rules
/* Language-specific typography */
:lang(ja) {
word-break: break-all;
line-height: 1.8;
font-feature-settings: "palt";
}
:lang(en) {
word-break: normal;
line-height: 1.6;
hyphens: auto;
}
Design and UX Considerations for Western Audiences
Visual Design Differences
This is where most Japanese companies stumble badly. Your English site shouldn't be a visual translation of your Japanese site. Full stop. It needs to be rethought from scratch.
Typography: Japanese web fonts (Noto Sans JP, BIZ UDPGothic) pair well with clean English typefaces like Inter, DM Sans, or the system font stack. Serve language-specific font files so you're not shipping unnecessary character sets to users who don't need them:
/* Only load Latin subset for English pages */
@font-face {
font-family: 'Noto Sans JP';
src: url('/fonts/NotoSansJP-Regular-latin.woff2') format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153;
font-display: swap;
}
Layout: Western users scan in an F-pattern. Prioritize a clear visual hierarchy with a single primary CTA per viewport. Reduce information density compared to your Japanese site by 30-50%. Yes, that much. It feels wrong to Japanese stakeholders when they see all that whitespace — we've had this exact conversation dozens of times — but it's what converts.
Imagery: Stock photos of exclusively Japanese settings can create a perception barrier. Use a mix of global imagery, or invest in photography that feels internationally relevant while keeping your brand identity intact.
Trust signals: This one gets constantly underestimated. Western B2B buyers look for case studies, testimonials with real names and companies, security badges, and clear pricing. Japanese sites often omit pricing in favor of "お問い合わせ" (contact us for pricing) — and this is an absolute conversion killer for Western audiences. They don't see it as standard practice. They see it as a red flag. We've watched this single issue torpedo conversion rates on otherwise solid sites.
International SEO Strategy
Hreflang Implementation
Proper hreflang tags aren't optional. They tell Google which language version to serve to which users:
<link rel="alternate" hreflang="ja" href="https://company.co.jp/" />
<link rel="alternate" hreflang="en" href="https://company.co.jp/en/" />
<link rel="alternate" hreflang="x-default" href="https://company.co.jp/en/" />
We see the same mistakes over and over:
- Missing
x-defaulttag (should point to your English version for global audiences) - Non-reciprocal hreflang (both pages must reference each other — Google straight-up ignores one-way declarations)
- Using
hreflang="en"when you should specifyen-USoren-GBfor market-specific content
Keyword Strategy
Don't translate your Japanese keywords. Research English keywords from scratch. Search intent and terminology differ way more than people expect:
| Japanese Keyword | Literal Translation | Actual English Search Term |
|---|---|---|
| 注文住宅 | Order-made housing | Custom home builder |
| 人材紹介 | Human resources introduction | Recruitment agency / staffing firm |
| 居酒屋 | Izakaya | Japanese pub / izakaya restaurant |
| 工務店 | Construction shop | General contractor / home builder |
Use Ahrefs, SEMrush, or Google Keyword Planner set to your target English-speaking market. Monthly search volumes, keyword difficulty, and SERP features will look completely different from what you see in Japanese search. Most agencies get this wrong because they start with the Japanese keyword list and work backwards. Don't.
Technical SEO Checklist
- Hreflang tags on all pages (reciprocal)
- Separate XML sitemaps per language, or one with hreflang annotations
- Google Search Console verified for each language version
- Server or CDN configured to serve from regions close to target audience
- Canonical URLs set correctly to prevent duplicate content
- Structured data (Schema.org) in English for English pages
- Open Graph and Twitter Card meta tags in English
- Page speed optimized for target markets (test from US/EU servers)
Performance Optimization for Global Delivery
Something that gets overlooked way too often: if your site's hosted exclusively in Japan, users in New York experience ~180ms of latency just from physical distance — before any server processing or resource loading even begins. That absolutely wrecks your Core Web Vitals.
CDN and Edge Strategy
| Provider | Edge Locations | Japan PoP | US/EU PoPs | Starting Price |
|---|---|---|---|---|
| Vercel | 100+ | Tokyo, Osaka | Extensive | $20/mo (Pro) |
| Cloudflare | 310+ | Tokyo, Osaka | Extensive | Free tier available |
| Fastly | 80+ | Tokyo, Osaka | Good | Usage-based |
| AWS CloudFront | 450+ | Tokyo, Osaka | Extensive | Usage-based |
For Next.js sites, deploying on Vercel gives you automatic edge caching and ISR (Incremental Static Regeneration) out of the box. Your English content gets cached at edge locations in North America, Europe, and Asia simultaneously.
For Astro sites, any CDN works brilliantly because you're serving pre-built static files. Deploy to Cloudflare Pages or Vercel and your site loads in under a second globally. Kind of magical when you actually see it working.
Image Optimization
Japanese sites often rely on heavy images with embedded Japanese text — it's a cultural design pattern that creates real headaches for English versions. For your English site:
- Use modern formats: WebP or AVIF (saves 25-50% vs JPEG)
- Implement responsive images with
srcset - Use Next.js
<Image>or Astro's<Image>component for automatic optimization - Replace text-in-image banners with real HTML text for SEO and accessibility
Legal, Compliance, and Payment Considerations
Privacy and Data Protection
Your English site probably targets multiple jurisdictions with different privacy requirements. Fun stuff.
- GDPR (EU/UK visitors): Requires explicit cookie consent, data processing transparency, right to erasure
- CCPA/CPRA (California): Requires "Do Not Sell" option, privacy policy disclosures
- APPI (Japan): Your Japanese business must comply regardless of where the site's hosted
Implement a consent management platform (CMP) like Cookiebot, OneTrust, or Osano that adapts its behavior based on the visitor's jurisdiction. Nobody enjoys setting this up — it's genuinely tedious — but the fines for getting it wrong are way worse than the implementation headache.
Payment Processing
If you're selling products or services to international customers:
- Stripe remains the gold standard for international payments in 2026, supporting 135+ currencies and available in Japan (Stripe Japan KK)
- Display prices in the visitor's local currency (USD, GBP, EUR)
- Consider Stripe Tax for automated international tax calculation
- Japanese payment methods (konbini, bank transfer) have no place on your English site — stick to credit cards, Apple Pay, Google Pay
Cost Breakdown and Timeline
Here's what Japanese businesses should realistically budget for a professional English website in 2026:
| Component | Budget Range (USD) | Timeline |
|---|---|---|
| Strategy & planning | $3,000–$8,000 | 2-3 weeks |
| Design (UX/UI) | $5,000–$20,000 | 3-5 weeks |
| Development (headless) | $15,000–$50,000 | 6-12 weeks |
| CMS setup & content modeling | $3,000–$8,000 | 2-3 weeks |
| Content translation (50 pages) | $3,000–$10,000 | 3-6 weeks |
| SEO setup & optimization | $2,000–$5,000 | 2-4 weeks |
| Total | $31,000–$101,000 | 12-24 weeks |
Ongoing costs typically run: CMS hosting ($50-$300/mo), hosting/CDN ($20-$200/mo), and content translation for new material ($500-$2,000/mo).
For a detailed estimate tailored to your business, reach out to our team or review our pricing structure.
FAQ
Should I translate my existing Japanese website or build a new English site from scratch?
Build a purpose-specific English site. Almost every time. Japanese and English audiences have different expectations for layout, information hierarchy, and content structure. A direct translation usually produces something that feels awkward to native English speakers — it preserves the structure of the original rather than the intent. Build your English site's information architecture based on English-market keyword research and user expectations, then fill it with professionally localized content.
What's the best CMS for a bilingual Japanese-English website?
Depends on your team. If your Japanese content editors want to work in familiar tools, microCMS or Newt offer native Japanese interfaces with solid i18n features. For companies planning to expand beyond English and Japanese, Contentful or Sanity provide stronger multi-locale support and bigger ecosystems. All of them work well with modern frontend frameworks like Next.js and Astro.
How much does it cost to build an English website for a Japanese company?
A professional English website on a modern headless architecture typically runs between $31,000 and $101,000 USD, depending on complexity, page count, and feature requirements. Simpler brochure sites land at the lower end; complex e-commerce or app-heavy sites push higher. Ongoing costs for hosting, CMS, and content updates typically run $500-$2,500 per month.
Should I use a .com domain or keep my .co.jp domain for the English site?
If your existing .co.jp domain has strong authority (check with Ahrefs or Moz), a subdirectory approach like company.co.jp/en/ lets you put that authority to work right away. If you're building a distinct international brand — or your Japanese site runs on legacy tech that's painful to extend — a separate .com gives you full independence. But avoid .co.jp for English-only audiences. It signals "Japan-only" to Western users before they've read a single word.
How long does it take to build an English website for a Japanese business?
A typical project runs 12 to 24 weeks from kickoff to launch. Roughly: strategy and planning (2-3 weeks), design (3-5 weeks), development (6-12 weeks), content creation and translation (running in parallel, 3-6 weeks), and testing/QA (2-3 weeks). The biggest timeline risk? Content. Always content. Getting approval on English translations from Japanese stakeholders can add weeks if you don't manage that process proactively — we've learned this the hard way, multiple times.
Do I need separate hosting in the US or Europe for my English site?
You don't necessarily need a separate origin server, but you absolutely need a CDN with edge locations in your target markets. If your site's statically generated — which we'd recommend for most content sites — a CDN like Cloudflare or Vercel's edge network serves cached pages from the location nearest to each visitor. US visitors get sub-100ms response times even if your origin server sits in Tokyo. It just works.
Can I use AI translation like DeepL or ChatGPT instead of professional translators?
For some content, yes. AI translation has gotten surprisingly good for product specs, technical documentation, and FAQ content — we've been genuinely impressed with how far it's come. But for brand messaging, marketing copy, and key landing pages? Invest in professional human translation, or at minimum go hybrid with AI translation plus professional human review (MTPE in industry speak). The cost savings of pure AI are tempting (90%+ reduction), but poorly translated marketing copy does real, lasting damage to brand credibility with native English speakers. We've seen it torpedo deals.
What are the most common mistakes Japanese companies make with their English websites?
The top five, in the order we see them: (1) Direct translation instead of localization — preserving Japanese sentence structures and formality levels that sound unnatural in English. (2) Keeping Japanese design patterns like dense text layouts and text-embedded images. (3) Hosting only in Japan with no CDN, so international visitors get sluggish load times. (4) Ignoring English-specific SEO and assuming translated Japanese keywords will just... rank. (5) Hiding pricing behind contact forms — Western B2B buyers treat this as a red flag, not standard business practice.