Tomasz Wojtasik

Category: SharePoint

  • Is This SharePoint Site URL Available?

    The problem

    When working on intranet solutions in SharePoint, a very common scenario is allowing users to create new sites — or at least request them through a form or custom application.

    In such cases, users are often asked to provide the site URL suffix — the part that comes after: https://tenant.sharepoint.com/sites/…

    Before creating a new site, we need to answer a simple question: Is the provided SharePoint site URL available, or is it already taken?

    Approach 1: Checking the Site via SharePoint REST API

    The most obvious approach is to simply check whether a site exists under the given URL.

    One way to do this is by sending a request to the SharePoint REST API and trying to read basic site information, such as the site title:

    https://<tenant>.sharepoint.com/sites/<siteUrl>/_api/web?$select=Title

    Based on the HTTP response, we might interpret the result as follows:

    • 200 OK
      The site exists and is accessible so the address is not available.
    • 403 Forbidden
      We don’t have permissions to access the site — which still means the site exists.
    • 404 Not Found
      The site does not exist, so the URL must be available.
      Right?

    At first glance, this logic seems correct. If SharePoint says the site is not found, we should be able to create a new site with that URL.

    Unfortunately, this assumption is wrong.

    Approach 2: Handling Deleted (Soft-Deleted) Sites

    The first approach works only as long as no one has deleted a site with the same URL.

    When a SharePoint site is deleted, it is not removed permanently right away. Instead, it goes into a soft-deleted state and remains there for 93 days, during which it can still be restored.

    During this period:

    • The site cannot be accessed
    • The REST API call returns 404 Not Found
    • A new site cannot be created using the same URL

    This creates a dangerous situation:

    The REST API indicates that the site does not exist, but SharePoint still blocks the URL. So while Approach 1 returns 404, the URL is not actually available. Clearly, we need a better solution — one that also accounts for deleted sites

    To properly validate whether a SharePoint site URL can be used, we can leverage the following internal SharePoint API endpoint:

    https://<tenant>.sharepoint.com/_api/GroupSiteManager/GetValidSiteUrlFromAlias?alias='mySite'

    This endpoint returns a validated site URL based on the provided alias.

    The behavior is simple but effective:

    • If the requested URL is available, the response contains exactly the same URL
    • If the URL is not available (because it already exists or is soft-deleted), SharePoint returns a modified URL, usually with a number appended (for example, mySite2)

    While this is not the most elegant solution, it gives us a reliable signal:

    If the returned URL differs from the requested one, the original URL is not available.

    Most importantly, this mechanism takes soft-deleted sites into account, making it far more reliable than checking site existence via REST.

    Summary

    Checking whether a SharePoint site URL is available is trickier than it looks:

    • Simply calling the site REST API and checking for 404 is not sufficient
    • Soft-deleted sites block URLs for up to 93 days
    • The GroupSiteManager.GetValidSiteUrlFromAlias endpoint provides a practical and reliable way to validate URL availability before site creation

    If you are building custom provisioning solutions, request forms, or automated intranet tooling, this extra validation step can save you from unexpected provisioning failures — and confused users.