Google Launch Checklist for a Bilingual Export Website

A practical pre-launch SEO checklist for bilingual export websites, covering product page parameters, locale switching, crawl/index eligibility, sitemap submission, and inquiry delivery with test steps and evidence.

Product Page Parameter and Procurement Question Checks

Before launch, verify that every product page answers the questions a procurement officer would ask. A page with only a product name and photo may be inadequate for a procurement decision; that is not itself proof of indexing ineligibility.

The goal is to make the page self-sufficient: a buyer should be able to evaluate the product without sending an inquiry for basic specifications.

What to check on each product page

Start with the technical parameters that appear on a data sheet. For an export site, these typically include material, dimensions, weight, packaging, MOQ (minimum order quantity), and lead time.

If the product is electrical, add voltage, power, and certification. If it is a component, add tolerance, operating temperature, or other relevant specs.

The exact list depends on your industry, but the principle is the same: every parameter that a buyer would need to shortlist the product must be visible.

Next, check for answers to common procurement questions. These are the questions that sales teams receive repeatedly: Do you provide samples? What are your payment terms? What certifications do you hold? What is your after-sales support policy?

If these answers are not on the page, a buyer must contact you to get them, which adds friction. Some answers, like payment terms, may be better placed on a separate page, but the product page should at least link to them.

How to test and what counts as passing

For each product page, compare the live page against the official product data sheet. Create a simple table with the data sheet fields on the left and the page content on the right. Mark each field as present, missing, or inconsistent.

A page passes only when every required field is present and matches the data sheet.

For an electrical-product test, compare the model, voltage and power against the approved sheet. Verify any conformity statement against its applicable documentation, and state which order conditions affect quantity or delivery commitments.

For procurement questions, use a similar checklist. Write down the five most common questions your sales team receives, then check whether the page answers them or links to a page that does.

A pass means the answer is findable within two clicks from the product page.

What to do when a page fails

If a field is missing, add it to the page template. If a value is inconsistent, correct it. If a procurement question is not answered, either add a short FAQ section to the product page or link to a dedicated FAQ page. Do not launch with incomplete pages.

Missing procurement information is a buyer-readiness concern. Record that gap without predicting a particular ranking outcome.

Locale Switching Functionality

A bilingual export site must let users switch between languages without confusion. The language switcher is not just a convenience; it affects how Google understands the relationship between your language versions.

If the switcher is broken, users may land on the wrong language. Test navigation and alternate-language annotations separately rather than assuming one proves the other.

What to check on the switcher

First, confirm that the language switcher is visible and clickable on every page, including product pages and the homepage. It should be in a consistent location, such as the header or footer.

Second, verify that clicking the switcher changes the URL to the correct language version.

For example, if you use /en/ for English and /zh/ for Chinese, clicking the Chinese option should take you to the /zh/ version of the same page, not to the homepage or a 404.

Third, check that the HTML lang attribute and the content language match. Google uses the content itself to detect language, but the lang attribute helps browsers and assistive technology. Fourth, verify that hreflang tags are correctly implemented.

According to Google's documentation on localized versions, you can use HTML, HTTP headers, or sitemap to specify alternate language versions, and you should use one implementation consistently. Each locale should list itself and the other versions.

For example, the English page should have hreflang="en" and hreflang="zh", and the Chinese page should have the same pair.

Manually click the switcher on every page template. For each click, record the URL before and after. A pass means the URL changes to the correct language version and the content is in that language.

Inspect the selected HTML, header or sitemap implementation for reciprocal language references and valid destination URLs. Search Console URL Inspection is not a dedicated hreflang validation report; a third-party validator is supporting evidence, not proof that Google adopted the annotations.

If the switcher does not change the URL, fix the link or the underlying routing. If the content does not change, check that the translation is actually loaded. If hreflang is missing or incorrect, add the tags to the HTML head or the sitemap.

Remember that Google detects language from content, not from hreflang or HTML lang, so a fully translated page is not automatically a duplicate.

But if you have two pages with the same content in different languages, they are not duplicates as long as the content is genuinely translated.

Crawl and Index Eligibility

Before launch, you need to confirm that Google can crawl your site and that your pages are eligible for indexing. This is not the same as guaranteeing indexing; Google may still choose not to index a page for other reasons.

But you can remove the technical barriers that would prevent crawling or indexing.

What to check on robots and meta tags

Check your robots.txt file to ensure that it does not block important pages. A common mistake is to block the entire site during development and then forget to remove the block.

However, note that blocking robots does not necessarily deindex a page; it only prevents crawling. If a page is already indexed and you block it, Google may keep the page in the index for a while.

To remove a page, you need a noindex tag, which requires crawl access.

Check the meta robots tags on each page. Ensure that no page has a noindex tag unless you intentionally want to exclude it. Also check for canonical tags.

If you have duplicate content, such as the same product page accessible via multiple URLs, set a canonical tag to the preferred version.

Use Google Search Console's URL Inspection tool. Enter the URL of a key page, such as a product page. The tool will show whether Google can crawl the page and whether indexing is allowed.

A pass means the tool reports that the page is crawlable and that indexing is allowed. If the tool shows a block, you need to fix the cause.

Check the actual robots rules for the relevant user agent and inspect current crawl restrictions with a live URL test. Keep the indexed record and live test separate; neither is a complete server audit. For meta tags, view the page source and look for the robots meta tag. A pass means there is no noindex and no conflicting directives.

If robots.txt blocks a page, edit the file to allow access. If a meta robots tag has noindex, remove it. If a canonical tag points to the wrong URL, correct it. After making changes, request indexing again in Search Console.

Remember that meeting these requirements does not guarantee indexing; it only makes the page eligible. Google may still take time to crawl and index, especially for a new site.

XML Sitemap Submission and Verification

Before launch, ensure your XML sitemap is generated, accessible, and submitted to Google Search Console. This helps Google discover your product pages and locale versions.

Check that an XML sitemap exists and includes all important pages.

For a WordPress export site, identify the actual sitemap URL from the active configuration or the sitemap declaration; do not assume all plugins use the same filename. Verify that it lists your product pages, category pages, and locale-specific versions (e.g., /en/ and /de/).

If you have a large catalog, confirm the sitemap is split into multiple files (e.g., sitemap-pages.xml, sitemap-products.xml) and that the index file references them correctly.

Verify the sitemap URL is accessible and error-free.

Open /sitemap.xml in a browser and check for HTTP 200 status. Look for XML errors, such as unescaped characters or missing closing tags.

Use Google Search Console's URL Inspection tool to test a few URLs from the sitemap to ensure they are crawlable and return 200. If you see 404s or redirects, fix the underlying issues before submission.

Submit the sitemap in Google Search Console and check status.

In Google Search Console, select your property, go to the Sitemaps report, and enter the sitemap URL. After submission, monitor the status: it should show "Success" with no errors.

If you see "Couldn't fetch," check that the sitemap is publicly accessible and not blocked by robots.txt. If you have multiple locales, submit each locale's sitemap or a sitemap index that includes all versions.

Test steps:

Navigate to the sitemap URL identified in the active configuration and confirm it loads.
Review the sitemap content to ensure all key pages are listed.
Submit the sitemap URL in Google Search Console.
Check the Sitemaps report for errors or warnings.

Pass evidence: The sitemap loads without errors, lists all important pages, and Google Search Console reports "Success."

Failure handling: If the sitemap is missing, regenerate it via your SEO plugin. If it contains errors, fix the underlying content issues (e.g., broken URLs, duplicate entries).

If Google Search Console shows errors, click through to see the specific issue and address it—common problems include blocked URLs or invalid date formats.

Inquiry Form Delivery Test

Your inquiry form is the primary conversion path for export buyers. Test it thoroughly to ensure submissions reach your team.

Check that form fields are complete and the submit button works.

Review the form on your product pages and contact page. Ensure all required fields (e.g., name, email, message) are present and that the submit button is functional. Test on both desktop and mobile to catch any JavaScript errors.

Test submission with sample data and confirm email notification.

Fill out the form with test data—use a real email address you control. Submit the form and verify that a confirmation message appears on the site. Then check the designated inbox for the notification email.

Confirm that the email contains the submitted details and that the sender address is correct.

Check that the email does not land in spam.

Email deliverability can be tricky. After submitting, check your spam folder. If the email lands there, adjust your email settings—for example, configure SPF/DKIM records or use a transactional email service like SMTP plugin.

Also, test with multiple email providers (e.g., Gmail, Outlook) to ensure broad compatibility.

Test steps:

Complete the form with test data and submit.
Verify the on-screen success message.
Check the designated inbox for the notification email.
Check spam folder and test with another email address.

Pass evidence: The form submits successfully, and the notification email arrives in the inbox (not spam) with correct details.

Failure handling: If the form does not submit, check browser console for errors and review the form plugin settings. If the email is not received, inspect the actual form recipient configuration, sending service response and delivery records. The general WordPress email setting does not establish how every form plugin routes messages.

If emails go to spam, check sender authentication and delivery diagnostics with the configured provider; no configuration change guarantees inbox placement.

Use the following checklist to document your pre-launch tests. Each row includes the check item, test step, pass evidence, and failure handling. This record helps you track completion and provides evidence for stakeholders.

Hypothetical product inquiry walkthrough

Imagine a buyer from Germany visits your product page for a stainless steel valve. They see the product specifications but have questions about minimum order quantity (MOQ) and lead time.

They fill out the inquiry form with their email and message: "What is your MOQ and lead time for 500 units?"

When they submit, the form should send an email to your sales team with the product name, the buyer's contact details, and their question. This is the expected behavior of the hypothetical test, not evidence that a real system has passed.

To test this scenario, use the checklist above: submit a test inquiry with similar details and verify the email content. If the email lacks the product name or message, adjust the form configuration to include hidden fields for product context.

This embedded record is your usable test log. Fill it out during your pre-launch checks and keep it for reference. It ensures you have evidence that each item works before going live.

Source： Google Search technical requirements

Embedded Test Record and Walkthrough

Use the following checklist to verify each item before launch. For each check, perform the test step and record the evidence. Only proceed when all items pass.

Check Item	Test Step	Pass Evidence	Failure Handling
Product page lists all required parameters (material, dimensions, weight, packaging, MOQ, lead time, etc.)	Compare page content against the official data sheet for each product.	Every required field is present and matches the data sheet.	Add missing fields to the page template; correct any inconsistencies.
Product page answers common procurement questions (samples, payment terms, certifications, after-sales)	Review the page or its links for answers to the five most common sales questions.	Answers are findable within two clicks from the product page.	Add an FAQ section or link to a dedicated FAQ page.
Language switcher is visible and clickable on all pages	Click the switcher on every page template and observe the URL and content.	URL changes to the correct language version and content is in that language.	Fix the switcher link or routing; ensure translations are loaded.
hreflang tags are correctly implemented	Inspect reciprocal HTML, header or sitemap alternate references.	No errors; each locale lists itself and the other version.	Add or correct hreflang tags in HTML or sitemap.
robots.txt does not block important pages	Inspect applicable robots rules and current URL-test evidence.	No applicable crawl restriction is identified in the recorded checks.	Edit robots.txt to allow access.
No page has a noindex meta tag (unless intentional)	View page source and check for robots meta tag.	No noindex directive on pages meant to be indexed.	Remove the noindex tag.
Canonical tags point to the preferred version	Check canonical tags on duplicate URLs.	Canonical tag points to the correct URL.	Correct the canonical tag.
Pages are crawlable and indexing is allowed	Use Search Console URL Inspection for key pages.	Tool reports "Indexing allowed" and no crawl errors.	Fix any crawl or indexing issues identified.

Add the exact URL, test timestamp, result and evidence location to each completed row. A new site with no impressions has no performance evidence yet; do not convert that into an indexing failure or a successful ranking claim.

For further investigation use the Google indexing diagnosis and SEO service scope.

Official references: localized versions, sitemap guidance and URL Inspection.

Next step

Complete one real bilingual product-and-inquiry test, retain the evidence, then repeat it across the remaining page templates.