The new site is live. The developer has sent the final invoice, the team has shared the link on WhatsApp, and for the first time in weeks nobody is asking you to approve a page. It is tempting to treat that as the end of the project. In practice it is the point where most of the problems that will matter over the next year are either caught or quietly planted.
Website maintenance after launch is a little different from the routine upkeep that comes later. The first weeks are about finding what the build missed, taking control of everything the developer set up, and getting a routine in place before anyone forgets how the site was put together. This post runs through it in the order it tends to come up, from launch day to the end of the first three months.
On launch day: the checks that cannot wait
These are the problems that cause the most damage if they slip through, and each takes a few minutes to check.
Search engines are allowed in
While a WordPress site is being built, developers often tick the setting under Settings, then Reading, that asks search engines not to index the site. If it is still ticked after launch, Google is being told to stay away. Log in and check the box is clear. If the site was built somewhere else first, also check that no leftover “coming soon” or maintenance plugin is still active.
Every form sends to the right place
Forms on a new site are often still sending to the developer’s test address, or to an address that was correct during the build and has since changed. Submit each form yourself and confirm where the email arrives.
The old addresses still lead somewhere
If this launch replaced an older site, the old page addresses are still in Google’s results, in people’s bookmarks and in links from other sites. Each one should redirect to the matching new page. Try a handful of old addresses from memory or from an old sitemap. The guide to fixing 404 errors after a redesign covers finding the ones you missed.
The site works on a real phone
Not a browser window dragged narrow on a laptop. A real phone, on mobile data, away from the office Wi-Fi. Open the homepage, the contact page and whichever page brings in the most business.
In the first week: take ownership of everything
During a build, the developer sets up a lot of accounts, often in their own name because it was quicker. The first week is the moment to sort that out, while everyone still remembers what was created.
- Domain: registered to your business, with your email address as the owner contact.
- Hosting: in your name, paid by you, with you holding the main login.
- WordPress: you have your own administrator account. The developer has a separate one, not a shared login.
- Premium plugins and themes: the licences are bought in your name, or you have the licence keys and know when they renew.
- Google accounts: Search Console and Analytics are owned by a business Google account, with the developer added as a user.
- Email: if the launch involved setting up mailboxes, you have the admin login for those too.
Write all of this into one document, with renewal dates. If it feels awkward to ask, remember that any good developer expects it. Where accounts and responsibilities sit between you, the developer and the host is explained in more depth in the post on who looks after which part of a website.
In the first month: catch what the build missed
No launch is perfect. The first month is when real visitors find the edges the developer did not test.
Keep a snag list
Every time you or a customer notices something odd, add it to a single list with the page address, a screenshot and the date. A typo, a button that does nothing, an image that looks stretched on one phone. Send the list to the developer in one batch rather than as twenty separate messages. Many build agreements include a period after launch for fixing faults, so check yours and use it before it runs out.
Confirm the data is arriving
Open your analytics a few days after launch and check visits are being recorded. Open Search Console, submit the sitemap if nobody has, and watch for pages that Google reports it cannot index. A tracking code that was left on the old site and never added to the new one is an easy gap to miss, and you only find out when you go looking for numbers that are not there.
Clean up the leftovers
Builds leave things behind: test pages, sample posts, dummy users, plugins used to migrate content, a staging copy on a subdomain that is still publicly reachable. Each is a small risk or a small mess. Ask the developer to list what can be removed and remove it.
Take the first proper backup
The developer may have taken backups during the build. Make sure there is a complete, current backup of the finished site, stored somewhere other than the hosting server, and that you know how to get hold of it.
What to do after a website goes live: the first quarter
By the end of the third month, the launch excitement has faded and the site needs to move into ordinary life. A few things belong here.
- The first round of updates. Plugins and themes will have released updates since the build. This first round is a good test of how the site responds to change, so do it carefully, with a backup, and check the key pages after.
- Uptime monitoring. If nobody set it up during the build, do it now so someone hears when the site goes down. What a basic check covers and where it falls short is explained in the post on monitoring whether a site is up.
- A look at speed. New sites are often fast at launch and then slow down as content and scripts accumulate. Take a reading now so you have a baseline to compare with later.
- Content that was “coming soon”. Every launch has a page or two that was meant to be finished afterwards. Either finish them or remove them from the menu.
What to ask the developer before they move on
The person who built the site knows things that are written down nowhere. Once they are busy on the next project, that knowledge gets harder to reach. Before the project is formally closed, ask them a few questions and keep the answers with your account document:
- Which plugins are essential, and which were only used during the build?
- Is anything customised in a way that an update could overwrite, such as edits made directly to a theme’s files instead of a child theme?
- Are there plugins or settings that should never be updated without testing first?
- Where are the original design files, fonts and image sources stored?
- Is there anything they would fix if they had another day?
That last question is often the most useful. Developers usually know exactly where the weak spots are, and most will tell you if asked directly.
Handing over to a routine
After the first quarter, upkeep stops being about the launch and becomes a schedule. The question is who runs it. There are usually three options: the developer who built it, someone in your business, or a separate provider. Developers are not always keen on ongoing upkeep once a build is finished, and that is fine as long as it is said plainly. If you go to a website maintenance company in India or anywhere else, hand them the account document from the first week and the snag list from the first month. Those two documents save hours.
How often that routine needs to run depends on what the site does, which is the subject of the post on how frequently a site needs attention.
Website maintenance after launch: the usual mistakes
- Letting the developer’s warranty period lapse unused. Faults found afterwards usually become billable work.
- Leaving the old site’s hosting running indefinitely. It costs money, it is not being updated, and if it is still reachable it can be found and abused.
- Cancelling the old hosting too early. Do not cancel until you have confirmed the new site, the email and any redirects all work, and you have a final backup of the old site.
- Adding plugins the week after launch. Wait until the site has settled before adding features, so new problems are easy to trace.
- Assuming the developer is still watching. Unless you agreed otherwise, once the final invoice is paid, nobody is.
Keeping it in good shape from here
If your new site runs on WordPress and you would like the routine to be someone else’s job from the start, our monthly care for a single WordPress site picks up where the launch left off, month to month, with nothing locked in.
Next in this series: Signs Your Website Needs Maintenance, by Urgency
