What should a maintenance page say beyond “Back soon”?
The website loads, but every address shows the same “Under maintenance” message. Customers cannot tell whether their existing booking is affected or only the new enquiry form is unavailable. A maintenance page should explain the limits of the interruption and provide a dependable next step. This original timeline is a planning example, not an announcement of an actual outage or a promised reopening time.
Ask whether the whole website must close
If only the booking tool is being replaced, service descriptions and contact information may remain available. Google Search Central recommends limiting functionality where possible during a temporary business pause instead of disabling the whole site. That does not make one approach suitable for every technical incident: review the affected system and safe operating boundaries with the development team.
Describe the scope in customer language. “Creating a new appointment is temporarily unavailable” is more concrete than “Infrastructure optimisation.” Do not claim that existing bookings are unaffected unless that has been confirmed. If records are unavailable, point customers to a real support channel able to establish their status.
Offer a credible update plan, not an invented deadline
A countdown to an uncertain time creates another problem when it reaches zero. Label an estimated return time as an estimate. If the time is not known, state when the next update will be provided and assign someone to publish it. Include the time zone when customers may be overseas.
A sample could say: “We are updating the new-booking screen. Our next status update will be at 15:00 Türkiye time.” Use wording like this only when the team can make that update. Leaving the same maintenance screen untouched for months is a different situation from a short interruption and needs a different content plan.
Match the visible notice to the technical response
MDN describes 503 as a response for temporary inability to handle a request; a Retry-After header can provide an estimated recovery time when available. Printing “503” in the design does not change the HTTP response. A developer should inspect the actual server response and check that normal pages and caches recover when service returns.
503 is not a long-term holding strategy. Google’s guidance distinguishes short disabling from a longer pause. This article does not recommend redirecting every address to one page or blocking search crawlers. Plan existing URLs and recovery checks together, without promising that a particular search position will be preserved.
Inspect the parts of a maintenance notice
Check that the alternative does not depend on the broken system
A contact link pointing to the unavailable form provides no way out. The telephone or email route should be current and monitored by the team. Do not ask customers to enter payment details into a public status form. Telling them to resubmit an existing request can also create duplicates.
Before maintenance, read the notice on a phone, try its links and record the recovery procedure. Afterwards, open a deep product or service address as well as the homepage. Our staging-access guide explains where changes can first be reviewed. Include interruption communication and a live recovery check within the website maintenance scope.
Frequently asked questions
Does every update need a maintenance screen?
No. Many content changes can be published while the site remains available. The need depends on the affected functionality and release method.
Does a countdown look more professional?
It is useful only when the schedule is real and actively maintained. An explanation and next-update time are more honest than displaying an uncertain deadline as a certainty.