Website Asset Checklist: What to Gather Before a Web Design Project

A website asset checklist is not a test you have to pass before a project can start.

Most business owners do not have every logo file, image, login, policy page, tracking code, and piece of copy neatly filed away. Some of it may be with a previous developer, designer, host, registrar, marketing agency, or internal team member. Some of it may not exist yet.

That is normal.

The point of the checklist is to make the invisible work visible. It gives you and your developer a shared map of the things a website project may need, so missing items can be found, recreated, replaced, or planned properly.

Using the interactive checklist

The interactive checklist is available as a separate full-width tool so the table has room for search, filtering, grouping, progress saving, notes, and a CSV export of your saved progress.

Open the interactive website asset checklist

You can export your saved checklist progress as a CSV from the interactive version.

Brand assets

Start with the core brand files if you have them.

The most useful items are logo files, logo variations, brand colours, fonts, and any brand guidelines. Vector logo files such as SVG, EPS, or AI are best because they can be resized cleanly, but a high-resolution PNG or PDF is still useful if that is all you have.

If you do not know what a vector file is, do not worry. Send what you have. A designer or developer can usually tell whether the file is good enough, whether a better version is needed, or whether the logo needs to be recreated.

Fonts are similar. Sometimes you have the font files. Sometimes you only know the font name. Sometimes the fonts are listed in a brand guide or old design file. If the font is commercial, check the licence before sharing the files directly.

Photos, video, and trust assets

Website projects often slow down when visual assets are left until the end.

Useful media can include:

• Product, venue, service, or process photos.
• Team and author photos.
• Icons, diagrams, and illustrations.
• Client, partner, award, or accreditation logos.
• Testimonials, review quotes, and supporting photos.
• Videos, animations, or hosted video links.
• A favicon or square app icon.
• A social sharing image for links shared online.

Original high-resolution files are better than images copied from an old website. If everything is only on the old site, that can still be a starting point, but it is worth checking whether better originals exist.

Social accounts and public contact details

The site should link to the right public profiles and show the right business information.

Gather the social profiles that are actually active and relevant. If the business has different accounts for different locations, teams, brands, or channels, decide which ones belong on this website.

Also confirm the public contact details: phone numbers, email addresses, physical addresses, mailing addresses, service areas, and where form submissions should go. These details sound simple, but they often affect contact pages, local SEO, structured data, maps, email routing, and enquiry workflows.

Access and integrations

Access details need more care than normal files.

Your developer may need to know where the domain is registered, where DNS is managed, where the site is hosted, who controls the existing CMS, and which tools are connected to the website. That can include analytics, Google Tag Manager, Search Console, CRM tools, newsletter platforms, booking systems, payment providers, live chat, reviews, maps, reCAPTCHA, SMTP, and other APIs.

Do not send passwords, API keys, or recovery codes by normal email or a standard upload link.

A good developer should give you a secure way to share sensitive access details, or ask you to invite them to the relevant account instead. Named user access is usually better than handing over a shared password.

If you do not know who controls something, that is useful information too. Domains, DNS, hosting, and analytics accounts are often held by a previous developer, agency, IT provider, or marketing supplier. Part of the project may be working out where those accounts live and getting ownership back into the right hands.

Content and page material

Content does not have to be final before the technical work starts, but it helps to know what exists.

Useful content assets include:

• An initial page list or sitemap.
• Existing page copy from the old website.
• Draft copy in documents or notes.
• Service, product, pricing, or offer details.
• Team bios, author bios, credentials, memberships, and accreditations.
• FAQs from real customer conversations.
• SEO notes, target keywords, Search Console exports, or PPC terms.
• Downloadable files such as brochures, menus, forms, white papers, or product sheets.

If copy still needs writing, mark it as a project task rather than pretending it is ready. That keeps the timeline honest.

Legal and policy pages

Policy content is easy to forget until launch week.

Depending on the site, you may need a privacy policy, cookie policy, terms and conditions, refund policy, delivery policy, booking terms, membership terms, or copyright and attribution notes.

Your developer can help identify where these pages are needed, but they cannot usually give legal advice. If a policy does not exist yet, flag it early so there is time to get the right wording from the right person.

What if you do not have everything?

You almost certainly will not have everything.

That is fine. The checklist is there to start useful conversations:

• Do we already have this?
• Who might have it?
• Is the current version good enough?
• Does it need to be recreated?
• Should it be produced during the project?
• Is it actually unnecessary for this website?

Some items can be gathered later. Some can be replaced. Some can be skipped. Some reveal important ownership or access issues that are better discovered early than during launch week.

If you are working with WildPress, I will help you work through this rather than expecting a perfect folder of assets on day one. If you are working with another developer or agency, they should provide a clear way to send normal project files and a secure method for sensitive access details.

For the wider delivery process, see my 6-step website build process. Once the project is closer to launch, the separate WordPress pre-launch checklist covers the final readiness checks before a site goes live.