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

• Best : Option A (English translation)
• to be avoided : Option B (transliteration)
• Migration-only fallback: Option C (drive ID)
• Adopt proposed naming convention for new site
• Adopt proposed naming convention for migrated content
• Adopt proposal for URLs

SharePoint Naming convention

Primary Strategy (All 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

4.2 Secondary Strategy (Where translation is not appropriate)

Use transliteration to convert unsupported characters into ASCII equivalents.

4.3 Migration Strategy (Legacy Shared Drives / AODocs only)

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

Example:
SHD_Finance-A1B2C3D4

5. Decision:

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: