1. Decision Context

As part of adopting SharePoint Online, a default root site already exists in the tenant.
Because it is not yet used and to avoid uncontrolled access, permissions have been temporarily removed.

While preparing the official SharePoint adoption, two urgent needs arise:

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

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

B. 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).

C. How should the default root site behave temporarily?

• Interim solution: redirect users to the current Drupal intranet until the SharePoint intranet is ready.

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

2. 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

3. Architectural Requirements

3.1 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

3.2 Information architecture constraints

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

3.3 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 overall score: Option A (English translation)
• Second-best: Option B (transliteration)
• Migration-only fallback: Option C (drive ID)

Primary Strategy (All New Sites)

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

Secondary Strategy (Where translation is not appropriate)

Use transliteration to convert unsupported characters into ASCII equivalents.

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

4. 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

5. Decision: 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: