Decision Context

As part of adopting SharePoint Online, two urgent needs arise:

What should be the strategy for SharePoint site names and URLs?

• Specifically: Should the site name be reflected in the URL?

How to handle unsupported characters or non‑Unicode languages in URLs?

• Options include translation, transliteration, or use of existing identifiers (e.g., Google Shared Drive ID).

The Technical Advisory Board must validate the long‑term naming & URL strategy because it affects:

• Information architecture
• Governance
• Migration effort
• Multilingual support
• Automations & provisioning
• User experience
• Integration with Teams & OneDrive
• Path-length stability (400‑char URL rule)
• Long-term platform scalability

Problem Statement

SharePoint Online URLs do not support non‑ASCII characters, such as:

• Accents (é, è, ô)
• Umlauts (ä, ö, ü)
• Ligatures (æ, œ)
• Non‑Latin alphabets (Arabic, Chinese, Cyrillic, etc.)

These characters cause:

• Failed migrations
• Broken OneDrive synchronization
• Encoded, unreadable URLs
• Compatibility issues across tools
• Longer paths risking the 400‑character limit

Therefore, the organization must formally decide:

• Whether site names should match URLs
• How to standardize URLs when names include unsupported characters
• Whether to translate names to English, transliterate, or use external system IDs

Architectural Requirements

URL technical constraints (SharePoint Online)

• Allowed: A–Z, 0–9, hyphens only
• Not allowed: accents, symbols, spaces, special characters
• URL counts toward 400-character path limit
• URLs must remain stable and permanent after migration
• URLs must support Teams interoperability

Information architecture constraints

• Naming standard must be consistent across:
  • SharePoint sites
  • Teams
  • Microsoft 365 Groups
  • Search
  • Metadata
  • Governance automation tools

Business & UX constraints

• Users must easily recognize:
  • The purpose of the site
  • Ownership (INT/EXT)
  • Department
  • Team
  • Region or geography
• Site URLs should remain clean, short, predictable

Recommended Decision

• Site Name
  • Option A (English translation using SyGPT to keep the meaning and with limitation to 30 characters)
  • to be avoided : Option B (transliteration)
  • Migration-only fallback: Option C (Prefix + drive ID)
  • Adopt proposed naming convention for new site
  • Adopt proposed naming convention for migrated content
• URL :
  • Option 1 : URL reflects name (normalized version via SyGPT)

SharePoint Naming convention

Golden rules

• External and internal are optional, and to be used if explicitly limited to Internal or external content.​
• Avoid special characters : # % & * { } \ : < > ? / + | "​
• No accents, diacritics, or non ASCII characters : Proposal is to use SyGPT to translate into english tokeep the meaning and keep it short​
• Names must be short <30 caracters​
• Human friendly names : Use PascalCase or Title Case for Site Names (but not URLs)​
• When possible avoid space​
• Avoid stacking long department or project names.​
• Use 3–5 meaningful elements maximum.​
• Depending the SharePoint structure, it will not be required to use all elements in the name likeDepartment, domain, team; while using HUB site this can reflect the organization and ease thenavigation.​
• HUB Site will be created explicitly, if a site is promoted it will be renamed.​
• DATE will use ISO format (YYYYMMDD)​

New Sites

* Ext and int removed. Only EXT if the site is completely for external vendor or party​
*1 : better to create dedicated hub​

Migrated content

 Follows the standard naming convention when possible with adjustments​

In case of library name too long , possibility to contact the owner to rename it using SyGPT totranslate into english to keep the meaning and keep it short​

URLs

URL will benefits naming convention​

For migration :​

• In case of library name, folder, file too long , possibility to contact theowner with a proposed renaming from SyGPT to translate into english tokeep the meaning and keep it short​
• If not possible we revert to Google IDs​​

DECISION

New Sites

OPTION A :Reflect the site name in the URL using English translations.

• Clean syntax
• Short and consistent
• Easy to govern
• Fully compliant with Microsoft’s URL restrictions
• Enhances user experience, searchability, and automation

Option B : (Where translation is not appropriate use Transliteration

Use transliteration to convert unsupported characters into ASCII equivalents.

Option C : Migration Strategy (Legacy Shared Drives / AODocs only)

For migrated content, add the prefix (SHD_ or AOD_) and optionally if Option A not applicable → append the Google Shared Drive ID when the name is ambiguous or unsafe.

Example:
SHD_Finance-A1B2C3D4

Should the Name Be Reflected in the URL?

Option 1 — YES: URL reflects name (normalized version – recommended)

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/FIN-Controlling

✔ Advantages

• Improves findability (people can guess URLs)
• Consistent with Microsoft 365 naming governance
• Works well with automation & provisioning
• Easier audit & support
• Matches industry best practices
• Helps avoid orphan or duplicated sites
• Short, stable naming helps avoid the 400‑char limit

✘ Drawbacks

• Names must be translated or transliterated
• Some business units may resist non-native naming
• Requires an authoritative naming dictionary

Option 2 — NO: URL uses a generated technical ID

Example:
Site Name: Finance – Contrôle de Gestion
URL: /sites/123abcXYZ

✔ Advantages

• Fully avoids unsupported characters
• Guaranteed uniqueness
• Stable even if site name changes

✘ Drawbacks

• Impossible for users to guess what a URL is
• Poor user experience
• Not suitable for enterprise intranet architecture
• Makes governance and audits harder
• Not aligned with M365 best practices

How Should We Handle Unsupported Languages?

Below are the clear options for dealing with non‑ASCII names in URLs.

Option A — Translate the name to English (using SyGPT for consistency)

Example: “Équipe de Gestion” → “ManagementTeam”

✔ Pros

• Aligns with international corporate standards
• Guarantees URL compatibility
• Clean, short URLs
• Matches most global enterprises’ practices
• Only requires one corporate dictionary (SyGPT can generate it)

✘ Cons

• Teams in non‑English regions may feel less represented
• Requires validation of translations

Option B — Transliterate the name (convert characters to ASCII)

Example: “Société Générale” → “SocieteGenerale”

✔ Pros

• Preserves local identity
• Predictable and intuitive result
• No need to translate terms
• Works well with automated rules

✘ Cons

• Some languages (Arabic, Chinese) transliterate poorly
• Still requires a dictionary for consistency
• Risk of ambiguous results

Option C — Use the Google Shared Drive ID as URL suffix

Example: Shared Drive ID = A1B2C3D4 → /sites/FIN-A1B2C3D4

✔ Pros

• Perfectly unique
• Great traceability from migration source
• No naming conflicts
• No translation needed

✘ Cons

• Very poor readability
• URL becomes meaningless for users
• Not scalable for future (non-migration) sites
• Only relevant for migrated content
• Inconsistent with new SharePoint sites created post‑migration

6. Evaluation Matrix

See also

The following section describes relevant documentation: