Unit

Adding and Deleting URLs Safely

Learn what URLs are, how applications store them, and how to add, validate, review, replace, and delete URL entries safely.

Adding and Deleting URLs

A URL, or Uniform Resource Locator, is the web address used to locate a resource on a network. A URL can point to a public web page, an internal page, a file, an API endpoint, or another service.

This lesson explains the basic URL lifecycle: create a URL record, validate it, review existing records, and remove or replace entries without breaking other parts of an application.

What a URL Is

A URL identifies where a resource can be found and often describes how to access it. For example:

https://www.example.com/help/contact?language=en#email

This example contains several components.

ComponentPurposeExample
ProtocolSpecifies the communication scheme used to access the resource.https
DomainIdentifies the host name of the website or service.www.example.com
PathIdentifies a location or resource within the domain./help/contact
Query stringContains optional parameters after a question mark.?language=en
FragmentPoints to a location within the resource after a hash symbol.#email

Absolute and Relative URLs

An absolute URL is a complete address that includes the protocol and domain, such as https://example.com/page. Use an absolute URL when the application requires a full external address or when the destination is outside your site.

A relative URL is interpreted in relation to the current site or page. An internal path such as /help/contact is a common relative URL. It does not include a protocol or domain because the application supplies the current site context.

An external destination URL points to another domain or service. An internal site path points to content within the current website. Always follow the format required by the specific application: some systems accept both formats, while others require an absolute URL.

Why Applications Store or Manage URLs

Applications store URLs as URL records: entries representing an address and, where applicable, metadata such as a label, status, owner, or usage information.

  • Links: A record can provide the destination for a hyperlink.
  • Redirects: A system can send requests from an old address to a new one.
  • Bookmarks: An application can maintain useful destinations for users.
  • Resource records: A URL can identify a document, image, video, download, or service.
  • Navigation entries: Menus and dashboards can use stored URLs.
  • Integrations: An application may connect to an external service through a URL.

A URL may be displayed directly to users, used internally by a system, or both. For example, a navigation record may show the label “Help Center” while the application uses its stored destination behind the scenes.

Adding a URL

  1. Open the area where URL entries are managed. It may be called URLs, Links, Navigation, Redirects, or Resources.
  2. Choose New, Add URL, or the equivalent action.
  3. Enter a descriptive name or label if the form provides one.
  4. Enter the destination address. Use a complete absolute URL when required, for example https://support.example.com/guide. For an internal page, use the expected internal format, such as /guide.
  5. Complete any required status, category, visibility, or publishing fields.
  6. Select Save, Create, or the equivalent control.
  7. Confirm that a success message appears and that the new entry is visible in the list or available in the feature where it should be used.

Example: Add an External Help Link

  1. Create a new URL entry.
  2. Set the label to Help Center.
  3. Enter an HTTPS destination, such as https://support.example.com/, using the real address supplied by the service owner.
  4. Save the entry.
  5. Open the resulting link and confirm that the intended help page loads.

Example: Add an Internal Navigation URL

  1. Create an entry for the internal page.
  2. Enter the application’s expected internal path, such as /account/settings.
  3. Save the entry.
  4. Open the navigation location and test the link as a user would.

Validating a Newly Added URL

Saving a record only confirms that the application accepted the entry. It does not prove that the destination is correct. Validate the address before considering the task complete.

  • Check the spelling and capitalization of the domain and path.
  • Confirm that the protocol is correct. Prefer https for external links when the destination supports it.
  • Check required paths, query parameters, and fragments.
  • Open or otherwise test the destination.
  • Confirm that it reaches the intended resource rather than an unexpected page.
  • Check for error pages, authentication failures, certificate warnings, or unexpected redirects.
  • Test the link from its actual navigation, page, integration, or redirect context.

A redirect sends a visitor or request from one URL to another. Redirects can be intentional, but an unexpected redirect may indicate a spelling mistake, an outdated destination, or a security problem.

Finding and Reviewing Existing URL Entries

Before changing or deleting a record, locate the exact entry and review its context. URL management screens commonly provide one or more of these controls:

  • Lists with pagination or navigation controls.
  • Search by label, domain, path, or record identifier.
  • Filters for status, type, owner, or visibility.
  • Sorting by name, date, status, or destination.
  • Details pages showing where the URL is used.

Review the full URL, label, status, destination, and usage. Similar labels can represent different destinations, so do not rely on the label alone.

Deleting a URL

  1. Find the exact URL record in the management list.
  2. Review its full destination and known references.
  3. Select the record and choose Delete, Remove, or the equivalent action.
  4. Read the confirmation prompt carefully. Verify the label and destination.
  5. Determine whether the action is immediate, reversible through a trash or history feature, or permanent.
  6. Confirm the deletion.
  7. Refresh or search the list to verify that the entry is no longer present.
  8. Test related pages, menus, redirects, documents, or integrations to ensure they behave as intended.

Some systems delete immediately. Others move records to a trash area or retain revisions. Do not assume that a confirmation dialog means recovery is available.

Consequences of Deletion

Deleting a managed URL record does not normally delete the destination page or resource itself. It removes the application’s stored reference, rule, or navigation entry. The destination may continue to exist at its original address.

Removal can still cause problems if other features depend on the record. It may break navigation, redirects, embedded resources, integrations, documents, or references in published content.

Check dependencies before deletion. Look for menus, pages, buttons, automated jobs, redirect rules, API settings, documents, and external systems that may use the URL.

CheckWhy It MattersSuggested Action
Current destinationThe address may still serve important content.Open it and confirm whether it is obsolete, incorrect, or merely changed.
References and dependenciesOther features may use the record.Search pages, menus, redirects, documents, and integrations; update them first.
Public visibilityPublic links can affect many users and search results.Assess user impact and follow the publishing or approval process.
Recovery optionDeletion may be difficult or impossible to undo.Check history, trash, revisions, exports, or backups before removing it.
Replacement or redirect requirementUsers may need a working alternative.Update the record or create an appropriate redirect when possible.

Safe URL Management Practices

  • Use descriptive, consistent labels, such as Help Center or Billing Documentation, rather than vague names such as Link 1.
  • Avoid duplicate records unless each one has a documented purpose.
  • Reject malformed addresses and verify domains before saving them.
  • Prefer HTTPS for external links when supported.
  • Remove obsolete destinations only after checking their dependencies.
  • For an address that has changed, update the record or redirect it instead of deleting it immediately.
  • Review important or widely used entries regularly.
  • Keep a recoverable record, export, or backup when deletion cannot be undone.
  • Document significant changes, including the old destination, new destination, date, and person responsible.

Permissions and Publishing Workflows

Adding or deleting URLs may require editor, administrator, content-manager, or other specific permissions. If an action is unavailable or the form rejects the change, ask an administrator to confirm your role and any domain restrictions.

Some applications save changes privately until they are approved or published. A saved URL may therefore be visible in the management interface but not yet visible to public users. Follow the required review, approval, staging, and publishing workflow, then test the published result.

Practical Example: Remove an Outdated URL

  1. Find the record that points to retired content.
  2. Open the destination and confirm that it is outdated.
  3. Check whether menus, redirects, documents, pages, or integrations still reference it.
  4. Update dependent references and identify a replacement destination if one exists.
  5. Remove the URL record only when it is no longer needed.
  6. Confirm that the record is gone and that users no longer encounter a broken link.

A broken link is a URL that no longer reaches the intended destination. Deleting a record can create a broken link if another feature still contains or expects that address.

Replace Rather Than Delete

Deletion is not always the best choice. If a destination has moved, identify the existing record and edit its destination when the system supports editing.

  1. Verify that the destination has changed.
  2. Update the URL or redirect target.
  3. Save the change and retest the destination.
  4. Check dependent pages and public navigation.
  5. Delete the record only if it is genuinely no longer needed.

Troubleshooting

The New URL Does Not Save

Likely causes include an empty required field, invalid URL syntax, insufficient permission, or an unsupported protocol or domain.

  • Complete every required field.
  • Check the URL syntax and remove accidental spaces.
  • Use the expected absolute or relative format.
  • Confirm your editor or administrator permission.
  • Check whether the application restricts protocols or domains.

The URL Opens an Error Page

A spelling mistake, removed destination, missing path, missing parameter, or incorrect protocol may cause the error.

  • Compare the stored value with the intended address.
  • Test the address directly in a browser.
  • Restore the missing path or required parameter.
  • Update the record or create an appropriate redirect if the content moved.

The Wrong URL Was Deleted

Similar labels or duplicate records can make selection errors more likely.

  • Restore the record from history, a backup, trash, or revision controls if available.
  • Re-create it using the verified destination if restoration is not available.
  • Use clearer labels and review the complete destination before future deletions.

Deletion Causes Broken Links Elsewhere

Other content or system features may have referenced the removed record, or a replacement was not created.

  • Identify and update dependent references.
  • Restore the removed record if necessary.
  • Add a replacement destination or redirect where appropriate.
  • Retest public pages, menus, and integrations.

Exam-Relevant Notes

  • A URL is a web address used to locate a resource.
  • An absolute URL includes a protocol and domain; a relative URL is interpreted within a site or page context.
  • The main URL components are protocol, domain, path, query string, and fragment.
  • Deleting a URL record is not the same as deleting the destination resource.
  • Always review dependencies before deletion.
  • Saving a URL does not prove that it works; open and validate it.
  • Permissions and publishing workflows can affect who may change or see a URL.

For related foundations, review HTTP, gathering links, and Apache configuration.