Website Launch QA Checklist for Multilingual Armenian Businesses

A multilingual launch is not one page checked three times. It is a set of distinct documents and user journeys whose relationships must remain accurate across language, URL, navigation, metadata, structured data and production behavior.

Use four QA passes

Keep the expected inventory in a machine-readable source where possible. A visual spot check can miss missing routes, duplicated canonicals, asymmetric hreflang, noindex pages in a sitemap, or broken localized assets.

Start with a route × language × indexability matrix

For each route, write the intended language, canonical URL, alternate versions, robots state and sitemap state. Do not force symmetry. If an Armenian or Russian article has not received adequate native editorial review, omitting it is safer than publishing an English body inside a localized shell.

Check more than visible paragraphs

Language QA includes the title, meta description, H1, navigation, breadcrumbs, buttons, forms, errors, empty states, image alternatives, captions, structured-data text and language-switcher destination. A localized page can look complete while an error message or schema description remains in English.

Responsive and accessibility checks

Test at narrow widths such as 320px and 390px, but also resize continuously. Fixed breakpoints do not reveal every overflow caused by long Armenian/Russian words, tables, code, URLs, navigation or buttons. Test zoom/reflow and text expansion without relying on horizontal scrolling for the page.

Keyboard and structure

Use a logical heading outline, landmarks, descriptive links, visible focus, keyboard-operable menus/forms and labels associated with controls. Confirm focus does not disappear behind a sticky header and that the language switcher communicates the current version.

Forms

Verify labels, instructions, required states, validation, error association, success/failure messages, consent, destination and sensitive-data warnings in every published language. A form is not complete because its submit button can be clicked.

Images and media

Check meaningful alternative text, decorative empty alternatives, dimensions/aspect ratio, lazy loading where appropriate, autoplay behavior, captions and reduced-motion/data considerations. Verify localized asset paths after the production build.

Search-facing controls must agree

Title, description and H1

Give each version a factual, language-appropriate title and description. The H1 should identify the page's primary subject without duplicating unrelated service intent. Native editors should optimize for natural search language, not literal word-for-word parity.

Canonical

Each genuine language version normally points its canonical to itself. Do not canonicalize Armenian and Russian pages to English simply because the subject is equivalent; that would treat the localized documents as duplicates rather than intentional versions.

Hreflang

Advertise only versions that actually exist and contain appropriate language content. Alternate sets should be reciprocal and include the page itself. If only an English article exists, omitting false HY/RU alternates is correct.

Robots and sitemap

Use the page-level robots directive for indexability decisions; robots.txt is a crawl control, not the preferred way to prevent indexing. Keep noindex resources out of the sitemap. Include canonical indexable URLs that the site genuinely wants in search results.

Structured data

Markup must match visible facts. Do not invent a Person author, dates, ratings, reviews, credentials or business facts. Validate JSON syntax and the relationships among Organization, WebPage, Breadcrumb, Service or BlogPosting entities as appropriate.

Production verification is a separate pass

A successful local build does not prove that hosting serves the same result. After upload, check the final HTTPS URL, status code, redirect behavior, canonical, robots, rendered language links, media, form destination, console/network errors and a sample of pages across every language and template.

1. Crawl the deployed inventory.Compare discovered routes with the approved matrix and sitemap.
2. Inspect representative templates.Home, service, contact, Blog/article and error behavior in each language.
3. Run synthetic checks.Use Lighthouse or equivalent as a regression signal, not a business outcome.
4. Inspect Search Console.Submit/verify the sitemap, inspect important URLs and watch indexing/query behavior after launch.
5. Record the release.Build identifier/date, file inventory, validation output, known limitations and rollback source.

ArmDark self-example: what the repository can and cannot prove

The pre-Phase-3C.1 ArmDark production baseline, recorded on 19 August 2026, contained 42 built HTML pages: 14 each for English, Armenian and Russian. Thirty-nine URLs were indexable and present in the sitemap; three Blog hubs were noindex. The repository validator reported 12 schema types, 0 errors and 0 warnings.

That evidence can support a transparent statement that the ArmDark build passed its own defined technical checks on that date. It cannot prove rankings, traffic, conversion, uptime, WCAG conformance, security, quality of every translation, or performance of unrelated client work.

Primary references

• Google Search Central: Localized versions — reciprocal hreflang among genuine language equivalents.
• Google Search Central: Build and submit a sitemap — include canonical URLs intended for search results.
• Google Search Central: Technical SEO guidance — robots.txt versus noindex and production rendering checks.
• W3C WAI: Easy accessibility checks — keyboard, focus and preliminary review.
• W3C WAI: Forms tutorial — labels, grouping, instructions and feedback.
• MDN: Web performance — synthetic and real-user measurement context.