Emoji In URLs, IDNs, And Keyword Stuffing: Google’s “Non-Canonical Cabinet” Is A Wake-Up Call For Technical SEO Execution

Google just did something I wish more platforms would do: it formalized the “weird questions” that operators and agencies deal with every week.

Search Central’s new YouTube series, The Non-Canonical Cabinet, starts with edge-case Technical SEO topics like emojis in URLs, non‑English characters in domains, and whether keywords in URLs matter for ranking. You can read the original coverage from Search Engine Journal.

On paper, this sounds niche. In real life, it’s not. These are exactly the kinds of questions that trigger risky site changes: replatforms, URL rewrites, international expansion, “SEO cleanups,” and brand/marketing experiments. And when URL decisions go wrong, the blast radius is brutal: broken links, lost rankings, analytics blind spots, wasted Crawl budget, and months of remediation.

My perspective (as Marius Dosinescu, building AYSA.ai): the biggest SEO wins don’t come from clever URL tricks. They come from execution discipline. You need to know what matters, what doesn’t, and how to ship changes safely—especially when multiple stakeholders want “just a small tweak.”

Table of contents

• A concise summary (for busy operators)
• What Google launched—and what’s actually new here
• Why “odd technical SEO” questions matter more than they look
• Domains vs. URL paths: the rules are not the same
• Emoji and special characters: crawlable doesn’t mean smart
• IDNs and punycode: the opportunity (and the risk) for international brands
• Keywords in URLs: the “tiny signal” that causes oversized arguments
• Hyphens vs. underscores: a small technical detail with real-world impact
• Where this intersects with AI search (AEO/GEO) and generative features
• A concrete SME scenario: the ecommerce rebrand that wants emoji URLs
• What agencies should rethink: sell less “URL magic,” ship more reliability
• Practical action plan: make URL decisions like an operator
• Where AYSA fits: monitoring + approved execution for technical SEO
• What to do next
• Sources and further reading

A concise summary (for busy operators)

• Domains and URL paths are governed by different rules. Domains must follow internet naming standards; URL paths are more flexible and can include many characters (including emojis) once encoded.
• Google’s message is consistent: keywords in URLs are a very small ranking factor and become largely irrelevant once Google has real content and other signals.
• Underscores are treated differently than hyphens in URL paths; Google has historically recommended hyphens as a word separator.
• The business risk isn’t the character set; it’s the change management. URL experiments can create redirect debt, analytics Attribution issues, and index bloat.
• What to do: stabilize your URL policy, document it, set monitoring, and ship changes only with an approval workflow—especially for international and platform migrations.

What Google launched—and what’s actually new here

Google’s Search Central team launched The Non-Canonical Cabinet, a sitcom-style series built around unusual technical SEO questions from site owners and the SEO community. The first episode focuses on what can be included in a domain name vs. a URL path (emojis, non‑English characters) and whether keywords in URLs influence rankings. Hosts include Gary Illyes and Cherry Prommawin, and Google is explicitly soliciting edge-case questions via comments (per the SEJ coverage).

Is this “new” information? Some of it, no. Pieces have been stated before:

• Google has long documented URL structure best practices in Search Central documentation (Google: URL structure).
• Google representatives have repeatedly downplayed keywords in URLs as a lightweight ranking factor (SEJ’s source article references earlier statements).

But here’s what is new and valuable: Google is productizing clarity for edge cases. They’re creating an “on-record” place to point clients, stakeholders, and internal teams when odd technical debates start eating roadmap time.

For SMEs and agencies, that matters because the biggest cost isn’t the answer—it’s the decision churn. A 30-minute debate about emoji URLs can turn into a 3-month refactor that creates a year of technical cleanup.

Why “odd technical SEO” questions matter more than they look

In day-to-day SEO, URL decisions rarely show up as “SEO tasks.” They show up disguised as:

• “Brand refresh”
• “We’re cleaning up old categories”
• “We want URLs to look nicer for social”
• “We’re expanding to new languages”
• “We’re moving from Shopify/WooCommerce to a headless stack”

And URLs are high leverage because they touch everything:

• Crawling & Indexing: new URLs can explode the number of crawlable pages, create duplicates, and confuse canonicals.
• Internal linking: site navigation, breadcrumbs, XML sitemaps, and contextual links all embed URLs.
• Analytics: attribution and channel grouping are sensitive to redirects, UTM handling, and referrers.
• Customer trust: users share URLs. They read them. They copy/paste them. They see them in receipts and SMS messages.

So when Google says “emoji in paths can be processed” or “URL keywords are tiny,” the takeaway isn’t “go do emoji URLs.” The takeaway is: don’t over-invest in URL micro-optimizations when the operational downside is real.

Domains vs. URL paths: the rules are not the same

A domain name and a URL path may look like one string in a browser bar, but they follow different technical constraints and governance models.

Domain names: constrained by standards and registries

Domain naming is bound by internet standards and policies. The SEJ source notes that Google references guidance from organizations like ICANN and the IETF, including older RFCs that define what hostnames can contain. Those standards historically allow letters, numbers, and hyphens in traditional ASCII domain labels (with additional systems enabling internationalized domains).

For business owners, translate that into a simple rule: you don’t get to invent the rules for your domain name. Your registrar, your TLD registry, and browsers will enforce what’s valid and what’s displayable.

URL paths: more flexible, but less predictable across systems

Paths (everything after the domain, like /category/product) can contain many more characters because URLs support encoding. As described in the SEJ coverage, browsers may percent-encode characters such as emoji into a representation like %F0%9F%90%94. Google says it can crawl and process these in paths.

That is not the same as “this is a good idea.” It means it’s technically possible. You still have to consider:

• How different browsers display it
• How different apps (social, chat, email clients) rewrite it
• How your CMS stores it
• How your server, CDN, WAF, cache, and logs handle it

In other words: the path is flexible, but your stack may not be.

Emoji and special characters: crawlable doesn’t mean smart

Let’s separate three distinct questions that get conflated:

1. Can it exist in a URL? Often yes, at least in the path via encoding.
2. Will Google crawl it? Google indicates yes for paths, and their documentation already covers encoding examples.
3. Should you do it? Usually no, unless you have a very specific UX reason and strong operational maturity.

The real problem: operational drift

Emoji URLs tend to create messy edge cases in places you don’t expect:

• Sharing & previews: some apps display the emoji, others show percent-encoded strings, others show replacement characters.
• Customer support: customers reading a URL over the phone or typing it manually is a disaster.
• Logging & debugging: encoded characters can make logs harder to scan and can break naive parsing scripts.
• Consistency: teams may “sometimes include emoji” and sometimes not, creating duplicates.

If you are a publisher or ecommerce brand, consistency beats cleverness. A clean, predictable URL policy is a growth asset.

What to anchor on: Google’s URL structure guidance

Google’s official documentation on URL structure emphasizes consistency and proper encoding for non-ASCII characters (Google: URL structure). That documentation exists because URL weirdness is rarely an SEO “hack”—it’s usually an engineering and maintenance problem.

IDNs and punycode: the opportunity (and the risk) for international brands

Internationalized Domain Names (IDNs) let brands use domain names in native scripts (e.g., Arabic, Chinese). Under the hood, those domains are represented in ASCII using punycode (commonly visible as labels starting with xn--), while browsers often display the native script form for readability.

In the SEJ source, Gary Illyes also highlights a practical risk: some characters across different scripts can look nearly identical (so-called “lookalike” characters), creating user confusion.

When IDNs make sense

IDNs can be a legitimate UX win when:

• Your audience is primarily local-language users
• Offline marketing (billboards, radio, TV) benefits from native-script readability
• Your brand name is natively written in a non-Latin script and transliteration causes confusion

Where operators get hurt: the non-SEO constraints

Most IDN pain isn’t Google. It’s everything else:

• Email and support tooling: many systems still assume ASCII in places you won’t notice until a form fails.
• Vendor ecosystem: payment providers, shipping labels, CRMs, ad platforms, and analytics pipelines may behave inconsistently.
• Security and trust: user confusion can rise if lookalike characters appear, even if you’re doing nothing wrong.

Also note the nuance from the SEJ source: emojis are not permitted in domains under current standards, though there have been edge allowances in some country-code contexts. Don’t build a brand strategy on exceptions.

A practical guideline for SMEs

If you’re an SME expanding internationally, your first decision is not “IDN or not?” It’s:

• Do we need separate country sites?
• Do we have the operational maturity to manage multiple properties?
• Will subfolders vs. subdomains vs. separate ccTLDs create more overhead than value?

IDNs can be part of the answer, but they are rarely the starting point.

Keywords in URLs: the “tiny signal” that causes oversized arguments

Google’s Gary Illyes calls keywords in URLs an “incredibly small signal,” per the SEJ source coverage. The framing matters: it’s not “never,” it’s “tiny,” and it mostly matters when Google has nothing else to understand a page (for example, a brand-new site with minimal signals).

That aligns with what many experienced SEOs have observed in practice: once your site has content, internal linking, external references, and user behavior signals, the incremental value of adding more keywords into a slug is usually negligible—and the downsides can be significant.

Why teams overdo keyword-heavy URLs

Keyword stuffing in URLs persists because it feels controllable. You can’t force Google to rank you, but you can force a slug to include “best-blue-widgets-in-dallas-cheap-free-shipping.”

It also persists because it used to be a more visible tactic in early SEO playbooks—and old habits die hard.

What to optimize instead (if you want outcomes)

For most SMEs, a better order of operations is:

1. Information architecture: categories, collections, service pages that map to real demand.
2. Index hygiene: control duplicates and parameters; get canonicals and robots rules right.
3. Content clarity: pages that answer the query with actual usefulness.
4. Authority building: real references, PR, partnerships, citations.
5. Performance & UX: technical foundations.

Clean URLs are part of this—but not the centerpiece.

Hyphens vs. underscores: a small technical detail with real-world impact

One of the most actionable points from the episode (as summarized by SEJ) is about separators: Google treats words joined by underscores in a URL path as one long word, while hyphens are the more standard separator across the web.

Google’s URL structure documentation also recommends hyphens for word separation (Google: URL structure).

Should you change existing underscore URLs?

Usually: don’t rush to rewrite existing URLs solely to replace underscores with hyphens if they’re already indexed and performing. Rewriting creates:

• Redirect chains and redirect mapping work
• Risk of broken internal links
• Temporary volatility in crawling and indexing
• Risky edge cases in analytics and marketing tracking

Instead, treat it as a policy decision for new URLs. Make a rule: “new slugs use hyphens.”

The bigger point: consistency beats micro-optimization

If half your site uses underscores, a quarter uses hyphens, and the rest are camelCase, your bigger problem isn’t Google’s tokenizer—it’s your governance. Consistency improves maintainability, internal linking patterns, and human trust.

Where this intersects with AI search (AEO/GEO) and generative features

The SEJ source quotes the series description: these are questions that don’t belong on a standard FAQ page but are still useful for Search and generative AI features.

That’s the quiet subtext: technical SEO now supports not only classic “10 blue links,” but also a world where:

• Search results include AI-generated summaries and citations
• Assistants and agents may pull, paraphrase, and recommend content
• Visibility becomes fragmented across surfaces

In that environment, URL keyword stuffing becomes even less interesting. AI systems don’t need your slug to understand your page. They need:

• Clear page purpose and structure
• Stable canonical signals
• Accessible, crawlable content
• Trust and consistency across the site

If you want a practical frame for “AI search visibility” as an operator, this is the direction we focus on at AYSA: make the site understandable and reliably accessible, then iterate on content and structure with monitoring and controlled execution. (Related: AI Search Visibility)

A concrete SME scenario: the ecommerce rebrand that wants emoji URLs

Let’s make this real with a scenario I see constantly.

Scenario

You run a mid-sized ecommerce store: 8,000 SKUs, 200 collections, and a lean team. Your brand manager proposes:

• Adding emojis to collection URLs for social shareability (e.g., /new-arrivals/ becomes /new-arrivals/🐔)
• Renaming product slugs to include more keywords (e.g., /products/classic-hoodie becomes /products/best-premium-cotton-hoodie-for-men)

What can go wrong (even if Google can crawl it)

• Duplicate URL variants: same page accessible at multiple paths due to encoding differences or app normalization.
• Redirect mapping workload: thousands of redirects to preserve equity—plus ongoing maintenance.
• Broken feeds and integrations: merchant feeds, email templates, affiliate links, QR codes, and influencer content break.
• Support and returns friction: customers copy/paste percent-encoded strings into support tickets.
• Index churn: Google has to re-crawl and re-evaluate large sections of the site.

The operator’s decision framework

Before any URL change ships, an operator asks:

• What measurable outcome will this change create (conversion rate, CTR, brand recall)?
• What’s the cheapest test to validate that outcome without rewriting the site?
• What’s the rollback plan?
• What monitoring will catch problems within 24–72 hours?

If the real goal is better social performance, test it with on-page creative, Open Graph metadata, landing page copy, and campaign URLs—not emoji slugs.

What agencies should rethink: sell less “URL magic,” ship more reliability

If you run an agency, Google’s statements are a useful forcing function. Clients will still ask for keyword-heavy URLs and “SEO-friendly slugs.” Your job is to reframe the conversation:

Shift the deliverable from “recommendations” to “safe execution”

Most SEO programs fail for one of two reasons:

1. They chase low-impact tactics because they’re easy to sell.
2. They identify high-impact fixes but can’t execute them safely in the real organization.

Technical SEO is where the execution gap is most expensive. A recommendation is cheap; a correct implementation with monitoring and rollback is valuable.

This is also why “approved execution” matters. Someone must own the step between “we should” and “it’s live.”

Use Google’s on-record guidance to end circular debates

When a stakeholder insists that keyword-dense slugs are “critical,” point to the on-record messaging: it’s a tiny factor and becomes irrelevant once Google has other signals (as relayed by SEJ from the Non-Canonical Cabinet episode). Then redirect energy to what will actually move the needle: content quality, crawl/index hygiene, internal linking, and authority.

Practical action plan: make URL decisions like an operator

Below is the playbook I recommend for SMEs and lean teams. It’s intentionally operational, not theoretical.

1) Write (and enforce) a URL policy

Document a policy that answers:

• Will we use hyphens only? (Recommended)
• Lowercase only?
• How do we handle stop words (and, the, of)?
• How do we handle non-ASCII characters in paths?
• Do we allow special characters at all?
• What is our canonical format (trailing slash or not)?

This sounds boring. It saves months.

2) Stop rewriting URLs “because SEO”

Rewriting URLs is justified when:

• You’re fixing a truly broken structure (e.g., infinite parameters indexed)
• You’re consolidating duplicates
• You’re doing a platform migration and must change paths
• You’re removing sensitive information or IDs that should not be public

Rewriting is not justified when the main argument is “more keywords in the slug.”

3) If you must change URLs, treat redirects like a product

Redirects are not a checkbox. They are a system. For any URL change project, you need:

• A redirect map (old → new)
• No chains (old → mid → new)
• Testing (top pages, templates, edge cases)
• Monitoring after launch (404s, soft 404s, crawl anomalies)

This is where many SMEs get trapped: a “small rewrite” creates 2,000 redirects, and nobody owns the system six months later.

4) Instrument monitoring, not just reporting

Most teams “look at SEO” monthly. That’s too slow for technical breakage. You want monitors that alert you quickly.

At AYSA, we think of this as an always-on layer: AYSA Monitoring.

What should you monitor?

• Spikes in 404s (especially on high-traffic pages)
• Index coverage anomalies
• Canonical changes / canonical drift
• Robots directives changes (especially accidental noindex/nofollow)
• Sudden growth in crawlable URLs (parameter explosions)

If you can’t monitor, you shouldn’t ship risky technical changes.

5) Keep Google Search Console close to your process

Even for non-technical operators, Search Console is the closest thing to Google telling you what’s happening. Make it part of the deployment routine: before/after checks for coverage, sitemaps, and URL inspection workflows.

If your team isn’t using Search Console regularly, your problem isn’t emoji URLs. It’s fundamentals.

Where AYSA fits: monitoring + approved execution for technical SEO

Most SEO tools stop at auditing and reporting. That’s where teams get stuck: a backlog of “should fix” items that never ship—or worse, they ship inconsistently and create new problems.

AYSA is built around a different model: monitor → prepare changes → ask for approval → execute accepted changes.

On a topic like URLs, this matters because execution requires care:

• Creating redirect rules safely (and avoiding chains)
• Updating internal links and templates consistently
• Ensuring canonicals match the new structure
• Keeping sitemaps aligned
• Watching for unintended indexation and parameter blow-ups

If you want to see how we frame AI-driven SEO execution (including technical and content workflows), start here: AI SEO Tools.

If you’re evaluating fit and scope, pricing and packaging matter: AYSA Pricing.

And if you want more practical editorials like this (written for operators, not theory), you can browse: AYSA Blog.

What to do next

1. Adopt a URL policy (hyphens, lowercase, stable patterns) and apply it to new pages immediately.
2. Freeze unnecessary URL rewrites—especially any “keyword density” motivated refactor.
3. Inventory special character usage in existing URLs (non-ASCII, underscores, unusual encodings) and document where it exists.
4. Set technical SEO monitors for 404 spikes, indexing anomalies, canonical drift, and robots accidents.
5. If international expansion is on the roadmap, decide on the architecture (subfolders vs subdomains vs separate domains) before debating IDNs.
6. Build an approval-based change workflow so marketing ideas don’t accidentally become permanent technical debt.

Sources and further reading

• Search Engine Journal: Google Launches A Video Series For Odd Technical SEO Questions
• Google Search Central: URL structure
• Search Engine Journal: Technical SEO category (context and ongoing coverage)
• Search Engine Journal: AI Search category (generative search context)

Note: The SEJ source references domain standards bodies and policies (IETF RFCs, ICANN resolutions) and summarizes what Google said in the video. Where your business depends on specific compliance or registry rules (especially for IDNs and ccTLD quirks), validate with your registrar/legal counsel and your engineering team before acting.

Related AI SEO resources

Continue the AI search topic inside AYSA.

Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.

AI SEO tools The commercial hub for AI SEO, AI search optimization and approved execution. AI search monitoring Track AI visibility, answer-engine mentions and the next actions worth approving. AI Overviews SEO Prepare clearer, more structured pages without promising guaranteed inclusion. SEO, AEO and GEO visibility A plain-English explanation of the search visibility layer AYSA prepares for.

Execution hubs

Turn this topic into a website action plan.

Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.

Technical SEO Open the related AYSA hub for deeper context and next-step workflow. AI search visibility Open the related AYSA hub for deeper context and next-step workflow. Monitoring Open the related AYSA hub for deeper context and next-step workflow. SEO research Open the related AYSA hub for deeper context and next-step workflow. Business owners Open the related AYSA hub for deeper context and next-step workflow. SEO glossary Open the related AYSA hub for deeper context and next-step workflow.

Written by

Marius Dosinescu

Marius Dosinescu is the founder of AYSA.ai, an entrepreneur focused on SEO automation, ecommerce growth, authority building and approved website execution for businesses that want organic growth without specialist overhead.

Author profile Dosinescu.ro

Share inShare on LinkedIn cpCopy article link fShare on Facebook @Share by email