Task: Implement the "page permanently deleted" mechanism for public entities

Implement the "page permanently deleted" mechanism for public entities

27.08.2026haih agent

Add proper handling for the permanent deletion of public pages without falling back to a standard 404.

Objective

Design and implement the "page permanently deleted" mechanism in haih-agent so that legacy URLs do not appear to be accidentally missing resources.

Currently, unwanted or accidentally created public entities cannot simply be deleted if an external URL might already point to them: a standard 404 Not Found does not explain to search engines and users that the page existed and was intentionally deleted.

A dedicated "page permanently deleted" scenario is required.

Core Idea

For a permanently deleted public page, the system should continue to process the old URI, but return a special deletion state instead of a standard 404.

The preferred HTTP status is 410 Gone.

410 semantically indicates that the resource existed but was intentionally removed and will not return. This aligns better with the requirement than 404, which does not distinguish between a URL that never existed and one that was deleted.

What Needs to Be Designed

1. Data Model

Determine how to store the fact that a URL has been permanently deleted.

Possible approaches:

  • a separate GoneRoute / RemovedRoute entity;
  • extending the existing SiteRoute system;
  • extending redirect rules with a new action type;
  • a tombstone record for the deleted entity.

Important: After the primary entity is physically deleted, information about the old URI must not disappear.

At a minimum, the following should be stored:

  • old URI;
  • deletion date;
  • source entity type;
  • optional public message / reason;
  • who performed the deletion;
  • optional link to a parent section or recommended alternative.

2. HTTP Behavior

For a registered permanently removed URI, return:

410 Gone

instead of a standard 404.

Meanwhile, unknown URLs that never existed should continue to return 404.

3. UI Page

Display a proper placeholder page, for example:

Page permanently deleted

This material is no longer available.

You can add:

  • a link to the parent section;
  • search;
  • homepage;
  • a suggested replacement, if specified.

This must not be a technical error page with a stack trace or an empty screen.

4. SEO

This mechanism is crucial for proper index management.

410 Gone gives search engines a more accurate signal than 404: the resource was intentionally removed and should no longer be considered temporarily missing.

This is useful for:

  • speeding up the removal of unnecessary pages from the search index;
  • reducing the number of garbage URLs in the index;
  • preventing recrawling of deliberately deleted content;
  • maintaining a clean site structure after mass migrations/cleanups;
  • distinguishing between genuine broken links (404) and intentionally deleted documents (410).

Important: If a deleted page has a full-fledged replacement with the same meaning, it is better to use a 301 redirect to the new canonical URL instead of 410. 410 is specifically needed when a resource is deleted without an equivalent replacement.

5. Entity Deletion Flow

Define the administrative workflow:

  1. The administrator selects "Delete permanently".
  2. Before deletion, the system saves the URI in a tombstone/gone-route.
  3. The main entity is deleted or marked as deleted, depending on the chosen architecture.
  4. The old URI starts responding with 410.
  5. Re-creating another entity with the same URI must be an explicitly controlled action rather than happening by accident.

6. Interaction with Redirect Rules

Define priorities:

  • if a URI has a 301 to an existing replacement, the redirect should work;
  • if a URI is marked as permanently gone, return 410;
  • rules must not conflict or yield ambiguous results.

A unified route rules processing order is required.

First Practical Case

conceptica.world currently has three accidentally created concepts about sculpting. They should not be deleted yet precisely due to the risk of turning existing public URLs into regular 404s.

Once the 410 Gone mechanism is implemented, they can be used as the first real-world case of permanent page deletion.

Acceptance Criteria

  • Storage model for permanently removed URIs is defined.
  • Administrator can delete a public entity while preserving a tombstone for the old URL.
  • The old URL returns HTTP 410 Gone.
  • Unknown URLs continue to return 404.
  • A custom "Page permanently deleted" user page exists for 410.
  • Priority between 301, 410, and standard 404 is defined.
  • The URI of a deleted page cannot be accidentally reused without an explicit decision.
  • Tests for 301, 410, 404, and rule conflicts are added.
  • SEO behavior verified: deleted page does not contain a self-referencing canonical and is not indexed as an active document.
  • After implementation, the mechanism can be applied to the accidental conceptica.world concepts.