Google’s documentation on URL structure says non-ASCII URLs are supported. Our own site is a counter-example worth looking at, because it accidentally ran the cleanest test of that claim we have seen: same site, same language, same publishing pipeline, two URL formats — 63 pages indexed on one side, 0 on the other.
We did not design this experiment. It is a by-product of getting lazy. Early articles got hand-written English slugs. Later, to save a minute per post, we let WordPress generate slugs from the Chinese titles. In the browser the address looks like Chinese. On the wire it is %e8%b0%b7%e6%ad%8c... — a long percent-encoded string. That single change of habit split our archive into two groups, and Google treated them very differently.
The numbers
In August 2026 we checked all 196 published articles on this site one by one in Search Console’s URL Inspection tool. 64 were indexed. 132 did not exist as far as Google was concerned.
| URL format | Pages indexed | Content language |
|---|---|---|
English semantic slug (/canonical-tag-seo-guide/) |
63 | Chinese |
Percent-encoded slug (/%e8%b0%b7%e6%ad%8c.../) |
0 | Chinese |
The content in both groups is Chinese. The topics overlap. The templates are identical. The only systematic difference is how the URL is encoded. Every single page in the zero column was a percent-encoded string.
Method (so you can reproduce or challenge it)
- Sample: all 196 published posts on tianwenseo.com, August 2026. Not a sample — the full archive.
- Instrument: Search Console URL Inspection, checked per URL, recording the four coverage states Google reports.
- Grouping: pages were split by slug format after the fact, not assigned in advance. This is a natural experiment, not a controlled one.
- What we did not control: publication date correlates with slug format (English slugs came first). Age is a plausible confounder and we say so in the Limits section.
If you want to run the same check on your own site, the useful part is not the total. It is the distribution across states:
| Search Console state | What it actually means | What to fix |
|---|---|---|
| URL is unknown to Google | Google has never heard of this page | Discovery: is it really in the sitemap, does anything link to it |
| Discovered – currently not indexed | Known, never crawled | Internal links, then wait; requesting indexing is a nudge, not a fix |
| Crawled – currently not indexed | Read, and Google decided to pass | This — and only this — is where content quality is the issue |
| URL is on Google | Indexed | Leave it alone and go rescue another page |
Most indexing advice starts at the third row. On the sites we handle, the damage is almost always in the first two.
Why percent-encoded URLs behave differently
The official position is that Google supports non-ASCII URLs, and that is true — Zhihu and Wikipedia rank fine with Chinese paths. But those domains have authority to spare. A percent-encoded path is long, opaque, and offers no lexical signal. On a site with essentially zero trust, those URLs sit at the back of the crawl queue, and the queue never reaches them.
So the honest reading of our data is not “Google cannot index non-Latin URLs.” It is: on a low-authority domain, percent-encoded URLs are a cost you have no budget for. Established sites can absorb it. New sites cannot.
What we changed, and the two traps in changing it
We rewrote 34 Chinese slugs to English semantic slugs. Two things went wrong that are worth knowing before you do the same:
- WordPress’s native
_wp_old_slugredirect is not reliable for percent-encoded slugs. We tested it. Some old URLs 301’d correctly, others did not. We ended up writing hard mappings in an mu-plugin to get 100% coverage. - A cached 200 is not a passing test. Verify after purging, or you are testing your cache, not your redirects.
Two silent failures that produced no error at all
A second site — machinery exporter, content and links both fine — had flat indexing for months. Two failures were stacked, neither of which logged anything:
Frozen sitemap cache. (Google on building sitemaps) Rank Math writes its sitemap cache to files named rank_math_{md5}.xml. The filename contains no “sitemap” string, so searching the filesystem for “sitemap” finds nothing. Default lifetime we measured in July 2026: 100 days. The admin screen showed a healthy sitemap. Google was being served a file from three months earlier, and new posts were not in it.
Scheduled posts that never publish. WP_CRON was disabled in wp-config.php and no system cron was configured to replace it. Scheduled posts sit in the Scheduled state forever, silently. That site had 176 posts stuck there. Every other site on the same server had the cron entry; this one was missed.
The general lesson: do not trust configuration, trust probes. Publish a test post scheduled one minute out and watch whether it fires. Read the sitemap report’s actual download timestamp and URL count instead of the plugin’s green checkmark.
The scale paradox
A catalogue site with 2,900+ product pages had a 36% index rate — roughly 1,916 product pages stuck at Discovered (full 90-day Search Console data, August 2026). Google knew about them and never came.
The counter-intuitive part: model-number long-tail queries drove 71% of that site’s clicks, while the head term the owner wanted to win produced impressions and no clicks. The revenue was in the long tail — and the long-tail pages were exactly the ones not indexed.
Our own site produced the same shape from the other direction: in a month where we published 150+ posts, the index rate fell to 33%. Publishing faster did not help. It diluted whatever crawl attention we had.
The highest-leverage fix we have measured
We built 294 internal links from the 64 indexed pages to 98 unindexed ones. Within 4 days, indexed pages went from 64 to 112 (August 2026, no other change deployed in that window).
Unindexed pages are usually orphans. A crawler that arrives at an indexed page and finds a link follows it; that is what “discovered” actually means in practice. Two things matter in how you build them: links should originate from pages that are already indexed and topically related, and the anchor should be the target page’s real title rather than a keyword you would like to rank for.
Backlinks matter too. But for a new site, internal links are the only lever you fully control and can ship the same day.
On “Request Indexing”
Search Console’s request-indexing quota runs at roughly 10 URLs per property per day. Two things we wasted it on, so you do not have to:
- Submitting pages that were already indexed. Check the state first; only Discovered and unknown pages are worth a slot.
- Submitting the same URL twice. Google’s own confirmation dialog says resubmitting does not change queue position. We tested it anyway. It does not.
Request indexing is an accelerator, not a rescue. If a page has no internal links and is not genuinely in your sitemap, requesting it ten times accelerates nothing.
Diagnostic order
| # | Check | Tool | Usual culprit |
|---|---|---|---|
| 1 | State distribution of unindexed pages | URL Inspection | Lots of “unknown” = discovery problem |
| 2 | URL shape | Just read the address bar | Percent-encoding, parameters, excessive length |
| 3 | Whether the sitemap is actually fresh | Sitemap report download time | Frozen cache; new pages absent |
| 4 | Internal link in-degree | Crawler or a database query | Orphans; pagination as the only entry |
| 5 | Whether scheduled jobs actually run | A probe post | WP_CRON off with no system cron |
| 6 | Now look at content | Compare against indexed pages | Thin, duplicated, no independent value |
The order is the point. Across the sites we maintain, the culprit is almost always in steps 1–5, and most published advice starts at step 6.
Limits of this study
- Not a controlled experiment. Slug format was not randomly assigned. English-slug pages are older on average, and age helps indexing. We cannot separate the two effects with this data.
- One site, one language. Whether this generalises to Cyrillic, Arabic, Thai or Korean paths is untested. The mechanism we propose — encoded length plus no lexical signal on a low-trust domain — would predict it does, but that is a hypothesis, not our finding.
- n=196. Large enough for a 63-vs-0 split to be striking; small enough that one site’s quirks could drive it.
- The internal-link result is a before/after, not a controlled trial. We deployed nothing else in that window, but we cannot rule out that Google’s crawl schedule shifted for unrelated reasons.
We publish these caveats because a 63-vs-0 headline is exactly the kind of number that gets repeated without them.
What this means if your site is not in Chinese
The transferable claim is narrow and, we think, defensible: if your domain has little authority, spend nothing on URL formats that cost the crawler extra effort. Percent-encoded non-Latin paths are the extreme case. Very long slugs, session parameters, and faceted URLs sit on the same spectrum.
And the diagnostic order transfers completely. Before rewriting a single title, find out how many of your pages Google has never crawled. If that number is large, content work is being spent on pages nobody will read.
Frequently asked
Does Google really fail to index non-Latin URLs?
No. Google indexes them on sites with authority. Our finding is about a site without any: there, encoded URLs never reached the front of the queue.
Should I rewrite my existing non-Latin slugs?
Only if those pages are not indexed. If they are indexed and ranking, changing URLs risks more than it gains. Check state first.
How long did the recovery take?
From the slug rewrite and internal-link build to a visible doubling of indexed pages: a little over a month. On a near-zero-authority domain, every feedback loop is measured in weeks.
Does being indexed mean traffic?
No. Indexing is admission, not a result. We have a client site where clicks rose 4.7× while inquiries fell to one twelfth of their previous level. That is a separate problem, and a separate study.
Related measurements from the same site
This is the second in a series of first-hand measurements we publish in English. The first: we tested 497 Chinese queries and found 80.9% already return an AI Overview — as far as we could tell, the first systematic measurement of AI Overview coverage on Chinese-language SERPs.
The original Chinese write-up of the indexing work, with the internal links and tooling referenced throughout, is here (in Chinese).