Hospital Website Launch Checks and Ongoing Support: What Should Be Included?

As a hospital website's launch date approaches, photographs and wording tend to get most of the attention. The final review also needs to cover what happens after a patient sends an inquiry, whether search engines can read the pages and who will update next month's opening hours. Put the results you need to verify in the launch checklist, and name the people and support responsibilities in the maintenance agreement.

Check publication, indexing and actual visibility separately

Start with public access. Can someone open the site on a phone outside the hospital without an administrator login? Check that service and medical team information appears, and that menus and call buttons work. Ask the web agency to confirm whether any search-blocking settings used during development have been removed.

Next, check indexing. The indexed data in Google Search Console's URL Inspection tool reflects the version Google last processed. A live test fetches and checks the current page, so the two results can differ just after a change. Passing the live test does not guarantee indexing. Ask the agency to record the URL and check date, and to distinguish the indexed result from the live-test result. See Google's URL Inspection guidance.

Finally, review actual appearances in search results and AI answers. Record the searches or questions and the date of each check. To be eligible as a supporting link in Google's AI Overviews or AI Mode, a page must be indexed and eligible to appear in Search with a snippet. Meeting those requirements does not guarantee visibility. This is the scope of Google's guidance on AI features. If “ready for AI search” is a handover requirement, specify whether that means checking access settings and page information or also reporting where the site appears.

Follow a test inquiry all the way to the receiving inbox

Do not finish the inquiry check when the submit button works. With a hospital staff member, send a test using test contact details and confirm that it arrives in the administrator screen or designated email inbox staff will use. On a phone, also check missing-required-field messages and duplicate submissions. Do not use real patient consultation details or sensitive information for testing.

Agree who receives inquiry notifications, who provides cover when they are away and who can access the inbox. If the site links to a Kakao channel or an external booking service, check the account and destination there as well. Distinguish the agency's responsibility for inquiry submission on the website from its responsibility for booking confirmation in an external service.

When reporting a problem, include the device, page, time and expected result instead of simply saying “inquiries do not work.” Ask the agency to record the fix and retest result in the same place. Assign responsibility for keeping the inquiry function working and, separately, for how quickly staff respond.

Define the difference between fixing faults and making changes

A support period alone leaves room for disagreement. Fixing an agreed feature that does not work, changing wording at the hospital's request and building a new page are different kinds of work. Use likely requests, such as changing opening hours or updating a doctor profile, to check what is included and what requires another quote. A list of actual requests makes the scope clearer.

The agreement should state when support starts and ends, where to send requests, support hours and the standard for an initial response to an incident. Distinguish that first response from full restoration. Also agree what help the agency will provide with issues it cannot resolve directly, such as an external booking-service outage or a platform policy change. If you need search-status checks and regular reporting, list the frequency and pages separately.

Receive account access as well as handover documents

Check that your hospital has the access it needs to the domain, website platform, Search Console and analytics tools. Review registered email addresses and administrators so login and account recovery can continue when staff change. Where possible, give people individual access permissions rather than passing around a shared password. Include the domain renewal date and who pays for renewal in the handover list.

Request administrator instructions, a list of what your team can edit, backup and recovery procedures, external services and recurring fees. Agree whether original files and source code are included, taking account of the platform and contract. Hosted platforms and licenses for paid themes or images may have separate conditions. Ask in advance which data you can export and what a move to another provider would cost.

If you are unsure what the hospital should handle and what to delegate, tell us about the ongoing work you need through BlinkAd's consultation page. Comparing production, launch checks and ongoing support in one list makes it easier to see what the agreement leaves out.