Google Search Central on October 14, 2026 published the first episode of The Non-Canonical Cabinet, a 12-minute 56-second YouTube video in which Gary Illyes and Cherry Prommawin answered questions about what characters can appear in domain names and URL paths, and in which the speaker answering the ranking question said keywords in a domain or URL become "basically irrelevant" the moment a page has content.

In Short

Two Google employees made a video explaining which letters, symbols and emoji are allowed in a web address, and whether stuffing keywords into one helps a site rank. Their answer is that emoji are not allowed in the main domain name but can go in the part after it, and that keywords in an address do almost nothing once there is real content on the page. For anyone naming pages, the message from Google is that short, readable addresses with words separated by hyphens are what it prefers, though its own written documentation goes further on encoding than the video does.

What was published

The video, titled "What can you actually put in a URL" on the Google Search Central channel, carries the date 14/10/2026 on its YouTube page. When the page was captured, it showed 7,591 views on a channel with 809,000 subscribers. It runs 12 minutes and 56 seconds and is available at youtube.com/watch?v=Mfvw43BbHy0.

According to the video description, it is "the premiere of The Non-Canonical Cabinet - a series where Google Search Developer Advocates Gary Illyes and Cherry Prommawin dig through the vault to answer the weirdest, most hyper-specific edge cases of SEO." The description frames these as "questions that don't belong on a standard FAQ page but are still useful for Search and generative AI features." The description closes with a one-line summary: "TL;DR: Just because you can doesn't mean you should. Keep URLs simple, readable and built for humans."

The format is scripted comedy around a recurring prop, a chicken, and a filing cabinet of odd questions. Most of the running jokes concern poultry. The technical content sits between them, divided into eleven chapters listed in the description, from "Who decides what goes in a domain name" through "Hyphens vs. underscores" to a recap at 11:34.

Two caveats apply to everything quoted below. The transcript is YouTube's automatic captioning, which contains errors set out in a separate section at the end of this article. And it carries no speaker labels. Where the exchange makes the speaker clear - Prommawin addressing "Gary" and Illyes answering - this article names the speaker. Elsewhere it attributes lines to the hosts.

The video's description points readers to one document under "Learn more": Google's "URL structure best practices for Google Search" page in the Search Central documentation, which was last updated on December 10, 2025, according to its footer. That page is the written policy against which the video can be checked, and the two do not say exactly the same things.

Domains: rules set outside Google

The first section of the video separates who controls a domain name from what Google does with it. Asked whether any "internet police" could stop someone registering an unusual domain, the reply was: "Nope. But ICANN might."

The hosts described ICANN, the Internet Corporation for Assigned Names and Numbers, as "basically the global nonprofit organization for the internet's address book," which, "along with the IETF define the technical rules for what can go into a domain name." The conclusion they drew is that domain names are a matter of internet infrastructure before search is involved. "The domain has to be part of the standard internet architecture before SEO even enters the chat. And Google generally supports anything that works on the official standard web infrastructure."

Prommawin then named the specifications. According to the transcript, domain names "follow the RFC 1035 and 1123 standards which are also what Google follows," permitting letters from A to Z, numbers and hyphens. Registration itself runs through a domain registrar, which the video did not discuss.

The hosts illustrated the outer limit of those rules with an anecdote: "I once saw a domain that was just 63 W's in a row." Sixty-three characters is the maximum length RFC 1035 allows for a single label in a domain name, so the example sits exactly at the edge of what the standard permits, though the video did not spell that out.

Internationalized domain names and Punycode

Beyond the Latin alphabet, the video covered internationalized domain names, or IDNs, which permit other scripts. "If you want to use Chinese Arabic or other language characters you can have them," Prommawin said.

Illyes explained the mechanism. Internationalized domain names "are transformed into puny code a text string that starts with Xn dash. So computers don't have a meltdown." The caption renders Punycode as "puny code" and the prefix xn-- as "Xn dash." He described a domain written in Chinese characters that "translates to a string of random letters and numbers behind the scenes. But browsers translate it back. So local users just see their native characters most of the time."

PPC Land has covered the same encoding in a different context. When Cloudflare added top-level domain data to its Radar platform in October 2025, covering more than 1,400 TLDs, it listed each internationalized TLD in both forms, with South Korea's 한국 appearing as xn--3e0b707e in its ASCII form.

The hosts also flagged a risk. "If you use an international character that looks like an English P, but it's actually a cerillic R that looks like an English P, you're going to confuse humans, me, and browsers alike. So, use it sensibly." The caption spells Cyrillic as "cerillic." The Cyrillic letter er looks almost identical to a Latin p, a resemblance the video presented as a usability problem; it did not mention lookalike domains used in phishing.

The business case the hosts made for IDNs was local recognition. "Using IDN can actually be quite helpful for brand recognition. If your business is very local, it helps people spell out and read your domain. If people cannot spell your domain, they cannot find you."

No emoji in domain names

Prommawin then proposed a domain made of a chicken emoji and a fire emoji. Illyes answered that the encoding step would work but the standards would not. "Generally, that's correct. The emoji would be converted to puny code, but then you have internet standards for domains and they don't allow emojis in the domain name. So, that's not possible."

He added a branding objection: "Also, why would any business owner want their domain name to look like a typo? Brand recognition is the goal."

The video's verdict is categorical, and it applies to the standards the hosts cited. It does not address whether any registry accepts such names in practice.

Keywords in URLs: "an incredibly small signal"

The passage most likely to interest search marketers came at 6:01. Prommawin asked whether a URL stuffed with "best grilled chicken in London, cheap, delicious, amaze, amaze, amaze" would rank first "immediately and forever."

Illyes's answer was unambiguous. "No. But no, not even a little. I mean, it is an incredibly small signal. It really only matters when we have absolutely nothing else to go on. Like if your site is 2 seconds old and has zero content, but even then the moment we see that you put some content on the page, the keywords in the domain and the URL in general become basically irrelevant."

That statement narrows when URL keywords matter to a single case: a new page with nothing else for Google to evaluate. It is consistent with, though more specific than, earlier written guidance. When Google released its guide to generative AI features in Search in May 2026, PPC Land reported that Google described keywords in a domain name or URL path as having "hardly any effect" on rankings beyond their appearance in breadcrumbs. The video adds the "nothing else to go on" condition, which the written guidance did not spell out in PPC Land's account.

Practitioner opinion has not always matched Google's framing. A survey of 131 search professionals that PPC Land covered in September 2026 ranked relevance as the top Google factor, and one respondent recounted surprise that an exact-match domain ranked for a competitive term with a fraction of the effort their main site required. That anecdote carried no data, and the survey did not report a score for domain keywords.

The recap at the end of the video put it in plainer terms: "stop trying to hack the search results with long keyword stopped URLs. It's 2026. We are smarter than that mostly." The caption renders "keyword-stuffed" as "keyword stopped."

URL paths: wide latitude, with encoding

The second half of the video moved to the path, the part of a URL after the domain. Here the rules are looser. According to the hosts, the path is defined "by the internet standards 66," which the caption garbles; the documentation page names the standard as IETF STD 66. Within it, "we can use the alphabets of the world numbers a bunch of special characters like exclamation marks and parenthesis."

Prommawin asked whether a chicken emoji in the path of a page selling "chicken gear" would count as thematic. Illyes dismissed the idea. "You know very well Google doesn't have a thematic poultry detector or whatever. It's just a character."

He then confirmed that such a path is technically usable. "If you still decide to have a URL path like /e emoji chicken-geear, Googlebot will actually crawl it and our system will actually process it. Browsers encode those special characters using percent encoding." The caption's "/e emoji chicken-geear" appears to stand for a path made of a chicken emoji followed by chicken-gear.

How Googlebot fetches such URLs is a matter of crawler behavior; how the characters get into the URL is a matter of encoding, and the video drew a sharp line between the two halves of an address.

Two encodings for two halves

Illyes explained the distinction after Prommawin prompted him with "Oh do tell professor." The domain part, he said, "is restricted by old system limits forcing it to use puny code encoding but the path everything after that.com uses percent encoding. It translates your chicken emojis UTF8 value into a string of percent signs and hexodimals like percent f0% person 9F whatever same chicken completely different technical translation."

The caption here mangles "hexadecimals" and the second "percent." The bytes are accurate as far as they go: the chicken emoji encodes in UTF-8 as F0 9F 90 94, so its percent-encoded form begins %F0%9F.

The hosts then summarized the split: "the front part of the URL is for domain name servers and the back of the URL is for the web servers."

Why emoji paths may not display

The objection the hosts raised to emoji in paths was display rather than crawling. "Not every browser or social media app is going to show that chicken emoji. Some will show a string of gibberish full of dollar signs and hashtags and whatnots."

The concern is where a link gets shared. "The URL shows up in various places where your users might actually see it. If it looks like a goat walked across a keyboard, they might not click it." A later line made the trust argument directly: "Some users rely on the address bar to understand where they are on a website. A clean URL generally builds trust."

Hyphens and underscores

At 10:45 the video turned to word separators. The hosts first noted that underscores are not available in domain names at all: "in the domain name, we already established we can only have hyphens, no underscore, right? But that's not a Google thing."

For paths, the explanation was specific about processing. "In the URL path though, Google treats the words linked together with underscores as one long word. Sometimes that might be fine because we might be able to use those words without separating them. We just recommend hyphens because visually and contextually it's the universal word separator across the web." The section ended with a plain instruction: "Use chicken dash gear, not chicken underscore gear."

Where the video and the documentation differ

Google's URL structure page and the video agree on the headline recommendations: descriptive words, hyphens over underscores, words in the audience's language. They differ in emphasis and, in two places, in substance.

Who encodes non-ASCII characters

The video says paths "can handle UTF8 characters like emojis and non-English characters" and that "browsers encode those special characters using percent encoding." Taken alone, that suggests site owners can leave raw characters in place.

The documentation puts the responsibility on the site. Under the heading "Use percent encoding as necessary," it states: "When linking to pages on your site, use percent encoding in your links's href attributes as necessary. Unreserved ASCII characters may be left in the non-encoded form. Additionally, characters in the non-ASCII range should be percent encoded."

The page then lists raw non-ASCII URLs - in Arabic, Chinese, German with an umlaut, and an emoji pair - under "Not recommended," and their percent-encoded equivalents under "Recommended." The emoji example is https://example.com/🦙✨, which decodes to a llama and a sparkles symbol. So where the video says the path can carry emoji and browsers will handle the encoding, the written guidance says the links on the site should already be encoded.

The documentation also states a stricter baseline: "Google Search supports URLs as defined by IETF STD 66. Characters defined by the standard as reserved must be percent encoded." Failing to meet the page's requirements, it warns, means "Google Search will likely crawl your site inefficiently - including but not limited to extremely high crawl rates, or not at all." The video makes no reference to crawl efficiency, a topic tied to crawl budget.

Why underscores are discouraged

On underscores, the two give different reasons. The video says Google treats underscore-joined words "as one long word." The documentation gives a historical rationale instead: "For historical reasons, we don't recommend using underscores, as this style is already commonly used for denoting concepts that should be kept together, for example, by various programming languages to name functions (such as format_date)." The written page does not state that Google's systems merge underscore-joined words into a single token. The video does, and adds that this "might be fine" in some cases.

What each leaves out

The documentation covers ground the video does not: it says Google Search "generally doesn't support URL fragments," recommends the equals sign and ampersand for URL parameters, notes that URLs are case sensitive so that "/APPLE and /apple" are distinct, and advises trimming unnecessary parameters. It also lists crawl traps - additive filtering, session IDs, infinite calendars and broken relative links - and points to robots.txt as one remedy. Faceted navigation, which produces many of those parameter combinations, received its own Google documentation update in December 2024.

The video, in turn, covers domains, IDNs, Punycode and the RFCs, none of which appear on the URL structure page. The page's only domain-level guidance concerns multi-regional sites, where it recommends either a country-specific domain such as example.de or a country subdirectory such as example.com/de/.

There is also a small inconsistency within the video. The domain section cites "RFC 1035 and 1123," while the recap says domains "are governed by EAN and RFC 1035, not Google," dropping RFC 1123 and rendering ICANN as "EAN."

Why this matters for marketers

URL decisions are cheap to make at launch and expensive to change later, which is why recurring questions about them reach Google's advocates. The video settles one long-running debate in plain language: Google's own staff describe keywords in URLs as close to worthless once a page has content. That leaves readability, trust and shareability as the operative reasons to choose one URL over another.

For sites in non-Latin scripts, the video and the documentation together give a fuller picture than either alone. IDNs are permitted in domains and handled through Punycode; native-language words are recommended in paths; and the documentation asks that those words be percent encoded in links.

The series also continues a pattern of Google explaining crawling and indexing mechanics through informal formats. PPC Land reported on October 13 that Search Off the Record hosts could not name the PDF size limit that Google's crawler documentation states as 64MB, a limit Google set out alongside a 2MB per-URL fetch limit in March 2026. The new video is scripted rather than conversational, but the same caution applies: a video is not documentation, and where the two diverge, the written page is the one Google links as the reference.

Earlier this year, Illyes argued that the web's JavaScript complexity creates problems for AI agents that simple HTML would have avoided. The URL episode makes a parallel argument at the address level. "Just because the technology allows you to be weird doesn't mean you should be weird," the hosts said.

The next episode, according to both the closing lines and the description, will "try to put a chicken in the robots txt file."

A note on the captions

The quotes in this article are taken verbatim from YouTube's automatic transcript and have not been corrected. Several caption errors affect technical terms:

  • "ICN" (3:27), "I can" (3:46) and "EAN" (11:34) all stand for ICANN, which the captions spell correctly elsewhere.
  • "SD letters" (3:51) most likely stands for ASCII letters, the term the chapter title at 3:46 uses.
  • "puny code" (4:23 onwards) is Punycode, and "Xn dash" is the xn-- prefix.
  • "cerillic R" (4:53) is a Cyrillic letter.
  • "the internet standards 66" (7:14) and "the ITF standard 66" (11:53) refer to IETF STD 66, the standard the documentation page names.
  • "chicken well emoji" (1:02) is unclear; no correction is evident from the context.
  • "www.com" (3:05) follows the anecdote about 63 W's and appears in the YouTube transcript itself; it is the caption's rendering of the spoken example rather than a real domain.
  • "hexodimals" and "person 9F" (8:49) stand for hexadecimals and percent 9F.
  • "/e emoji chicken-geear" (8:12) appears to be a chicken emoji followed by chicken-gear.
  • "keyword stopped URLs" (12:12) stands for keyword-stuffed URLs, and "URL pass" (11:46) for URL paths.
  • "gling around" (1:16), "bet an eye" (10:19) and "non-cononical" are further transcription slips.

The chapter timestamps in the description match the section breaks in the transcript to within a few seconds.

Timeline

Summary

Who: Google Search Central, with Gary Illyes and Cherry Prommawin, described in the video as Google Search Developer Advocates. The rules they cite come from ICANN and the IETF.

What: The first episode of a new YouTube series, The Non-Canonical Cabinet, explaining what characters are allowed in domain names and URL paths. The hosts said emoji are not permitted in domain names under internet standards, that IDNs are converted to Punycode, that emoji and non-ASCII characters in paths are percent encoded, that Google treats underscore-joined words as one word, and that keywords in URLs become "basically irrelevant" once a page has content. Google's written URL documentation differs on who should percent encode non-ASCII characters and on why underscores are discouraged.

When: The video carries the date October 14, 2026. The URL structure documentation it links to was last updated on December 10, 2025.

Where: The Google Search Central YouTube channel, at youtube.com/watch?v=Mfvw43BbHy0, with the related guidance in the Search Central documentation.

Why: The series addresses edge-case questions Google receives at events and on social media that do not fit a standard FAQ. For marketers, the episode reduces the case for keyword-rich URLs to almost nothing and leaves readability, encoding and display across apps as the practical considerations in URL design.