Direct answer

423 Locked means the source or destination resource of the request is locked.

What to remember
  • A lock can prevent conflicting changes to documents, CMS records, media files, redirect maps, publishing packages, shared folders, and configuration.
  • RFC 4918 says a 423 response should contain an appropriate precondition or postcondition code, such as lock-token-submitted or no-conflicting-lock .
  • A content platform can use 423 when another editor holds the record lock, a migration freezes a content type, a release process locks a redirect map, or a publishing job owns the package.

01

Definition

Direct answer.

423 Locked means the source or destination resource of the request is locked.[1]

It originated in WebDAV, where clients can lock resources before modifying them.

DELETE /documents/report.docx
→ 423 Locked

The file exists. A lock prevents the operation.

For SEO, the distinction is simple:

423 on a write, move, or delete operation
→ can be correct workflow behavior

423 on an ordinary public GET page
→ usually an availability or routing defect

What a lock protects.

A lock can prevent conflicting changes to documents, CMS records, media files, redirect maps, publishing packages, shared folders, and configuration.

The server can require a valid lock token before a change succeeds. This is different from authentication. A user can be authorized to edit while lacking the active lock token.

02

Mechanism

WebDAV context.

RFC 4918 says a 423 response should contain an appropriate precondition or postcondition code, such as lock-token-submitted or no-conflicting-lock.[1]

A useful response can identify the locked resource, scope, token requirement, expiration, and recovery route. Do not expose confidential user details in a public error body.

CMS publishing.

A content platform can use 423 when another editor holds the record lock, a migration freezes a content type, a release process locks a redirect map, or a publishing job owns the package.

The editor interface should preserve the draft and explain the next action. Do not retry the same update automatically until the lock expires. Blind retries add load without changing the precondition.

Public page retrieval.

A reader requesting:

GET /guides/canonical-tags/

should normally receive 200.

If it returns 423, investigate lock middleware applied to every method, a file lock leaking into delivery, a WebDAV handler intercepting GET, a deployment freeze rule, a storage mount, CDN cache, or a bot-specific security rule.

Public reading should not require an editing lock token.

03

Examples

Google crawling.

Google says persistent 4xx responses, except 429, are treated as unavailable content. Google does not use the body for indexing, and previously indexed URLs can be removed over time.[2]

There is no public 423-specific exception. If a public page temporarily returns 423 during publishing, restore the stable response quickly. Do not use 423 as a generic maintenance status.

423 versus 409.

Use 423 when a lock specifically prevents the operation. Use 409 for a broader conflict with current resource state.

Active WebDAV lock → 423
Slug already belongs to another article → 409

423 versus 412.

Use 412 when an HTTP precondition such as If-Match fails. Use 423 when lock state blocks the action. An edit can encounter both a stale ETag and an active lock. Return the most specific useful response under the client contract.

04

Boundaries

Cache behavior.

Do not cache 423 as the public page representation. Review CDN error caching, reverse proxies, service workers, API client caches, and regional edges. A lock can expire while a cached error remains.

Monitoring.

Track:

METHOD:
RESOURCE:
LOCK_TYPE:
TOKEN_PRESENT:
LOCK_CREATED:
LOCK_EXPIRES:
FINAL_STATUS:

Segment expected editing conflicts from public GET failures.

Recovery checklist.

  • Method confirmed.
  • Locked resource identified.
  • Lock token checked.
  • Expiration checked.
  • User draft preserved.
  • Public GET tested.
  • 409 and 412 distinguished.
  • Cache purged.
  • Repeated retries bounded.
  • Google-facing route restored.
  • Lock telemetry monitored.

Evidence limits.

RFC 4918 defines WebDAV lock semantics. Non-WebDAV applications can adopt 423, but their lock contracts are application-specific. Google publishes broad 4xx behavior rather than a 423-specific indexing rule.

How to verify this guidance.

This article is intended for Developers, CMS operators, infrastructure teams, and technical SEOs. Its evidence basis is RFC 4918 and current Google crawler documentation. Use 423 when a valid lock prevents an operation, include machine-readable lock context where supported, and keep public HTML GETs on ordinary successful or truthful error responses.

For a practical verification exercise, use this model: Editor acquires a lock, another edit receives 423, then the lock expires or transfers and the update succeeds. A 423 describes an operation blocked by a lock, not a missing resource.

The package verification record states: RFC 4918 423 semantics and lock-condition examples were checked on 2026-08-05. Google’s current broad 4xx crawler handling was checked. 423 is not presented as a universal maintenance status. Application-specific lock metadata remains bounded.

Related verification paths: Review alongside HTTP 409 conflict coverage. Review alongside HTTP 412 precondition coverage. Review alongside publishing-lock and change-control guidance.

The duplication and search-intent review found: No HTTP 423 article appeared in the reviewed archive or prior package ledger. The subject is distinct from 409 conflicts, 412 preconditions, 428 required preconditions, and 431 header errors.

References

Sources behind this record

  1. RFC 4918: WebDAV — RFC Editor (accessed August 5, 2026)
  2. HTTP status codes for Google crawlers — Google Crawling Infrastructure (accessed August 5, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.

Claim limit

RFC 4918 defines WebDAV lock semantics. Non-WebDAV applications can adopt 423, but their lock contracts are application-specific. Google publishes broad 4xx behavior rather than a 423-specific indexing rule.