How to update a website (even one you didn’t build)

Why updating a website feels harder than it should

Changing a sentence on a website ought to take two minutes. Often it takes an afternoon, because nobody remembers how the site was made, who has the login, or how changes get from someone’s computer to the live address. Small businesses inherit sites from a former freelancer; freelancers inherit sites from a client’s nephew. The edit is easy. Finding the way in is the hard part.

This guide covers the whole path, for any kind of site.

1. Find out what the site is built with

Websites are made in a handful of broad ways, and each is edited differently:

• A hosted website builder. You edit pages in your browser, in a visual editor, and press publish inside the builder.
• A content management system (CMS). The site has an admin area, usually at an address like yoursite.com/admin or similar, where you log in and edit pages and posts.
• Files. The site is a set of HTML, CSS, JavaScript and image files. You change the files and publish them to your host.
• A custom application. A developer built something specific, with its own code and often a database. Changes usually go through that developer.

How to tell which one you have:

• Ask. Whoever built the site, or whoever pays the hosting bill, usually knows.
• Check the footer and the page source. Builders and CMSs often leave their name in the footer, or in the page source (right-click the page and choose “View page source”).
• Look at the emails. Search your inbox for receipts or renewal notices. They tell you who hosts the site and who registered the domain.

2. Get access of your own

Once you know the platform, you need a way in. Ideally that means your own login, not someone else’s password passed around by email. Most builders, CMSs and hosting accounts let the owner add another person as a user. If you’re the owner and the login belongs to a former developer, contact the platform’s support with proof that the domain or the account is yours.

Write down, in one safe place:

• where the site is hosted and which account it’s on,
• where the domain is registered,
• how you log in to edit it,
• how changes get published.

That note will save the next person (or you, in a year) the whole first hour.

3. Save a copy before you change anything

Before your first edit, keep a copy of the site as it is now. In a builder, that might be a duplicate of the page or the site’s version history. In a CMS, export the content or take a backup through your host. For a site made of files, copy the folder or download it as a zip. If something goes wrong, you want to put it back in minutes, not rebuild it from memory. There’s more on this in how to back up a website.

4. Make the change

How you edit depends on step 1:

• In a builder, open the page, click the text or picture, change it and save. Changes are usually saved as a draft until you publish.
• In a CMS, log in to the admin area, find the page or post, edit it and save as a draft or preview it.
• In files, open the file for the page in a code editor, change the text or the image, and save. If you’re not comfortable with HTML, change only the words between tags and leave everything else alone.
• In a custom application, send the developer a clear request: which page, what it says now, what it should say, and a screenshot.

The most common updates are small: new opening hours, a price, a staff photo, the year in the footer, a new page for a service. Do one change at a time, so if something looks wrong you know what caused it.

5. Check it before it goes live

Look at the changed page on a large screen and at phone size. Check that:

• the words are right and spelled correctly,
• images load and aren’t stretched or cut off,
• nothing has moved out of place on a narrow screen,
• links on the page still go where they should.

If someone else needs to approve the change, or it’s something customers rely on, publish it to a private staging copy first and send them the link. We explain why in why check a staging version before you publish. For phone layouts, see how to make a website mobile friendly.

6. Publish

Publishing means putting your change on the live address. In a builder or CMS there’s usually a Publish or Update button. For a site made of files, it means sending the changed files to your host, by whatever method the site uses: an upload through the host’s control panel, a file transfer program, a deploy command, or a push to a code repository that publishes automatically.

7. Look at the live site

Open the real address in a private browser window (so you don’t see an old copy stored by your browser) and check the change again, on your phone as well. If you still see the old version, wait a few minutes and reload; some hosts keep a cached copy for a short time.

8. Note what you did

Add a line to your notes: the date, what changed and who asked. When a client later says “the price on the website is wrong”, you’ll know when it last changed and why.

Updating a site you didn’t build

If you’ve taken over a site from someone else, add three steps before you start:

1. Confirm who owns the domain and the hosting account, and that it’s the client, not the old developer.
2. Ask the old developer (politely) for anything that isn’t in those accounts, like the original files or design.
3. Make a small, harmless change first, such as the footer year, so you learn the publishing path before anything important depends on it.

Updating many sites

If you look after several sites, the time goes into switching between them: different logins, different editors, different ways of publishing. A single routine for every site, with one list of what’s live, makes a bigger difference than any one tool. We wrote about that in how to manage multiple websites.

How Devdwell helps with updates

Devdwell is a desktop app for Mac and Windows that keeps the sites you build or look after in one place, as files. You can bring an existing site in from a folder or a zip, then say what you want changed in plain words, or click the part of the page you mean, and see the change in a live preview beside you, at desktop, tablet and phone sizes. Publishing is one button, to a private staging link, the live address, or both. It’s in early access; see editing in Devdwell.

A quick update checklist

• Know what the site is built with and where it’s hosted.
• Have your own login, not a shared password.
• Save a copy of the current version.
• Make one change at a time.
• Check it at desktop and phone sizes.
• Use staging when someone else needs to approve it.
• Publish, then check the live address in a private window.
• Note the date and what changed.

Questions