How to publish better design case studies

1. Give every project its own permanent page

A project needs a URL that opens the project itself—not a homepage, filtered grid or temporary modal. A clear pattern such as /work/project-name makes the case easier to share, index and measure.

Keep that URL after a redesign. If it must change, add a permanent redirect to the new address. Use a canonical URL when the same content is available at more than one address.

2. Make the important content available without fragile interactions

Google can render JavaScript, so client-side rendering is not automatically bad. The problem is an empty app shell, content that appears only after a click, or a page that fails when one script or API request is slow.

Put the project name, description, credits, images and normal HTML links in the rendered page. Static generation, server rendering and dependable pre-rendering are all good approaches. Test the result in a slow connection and in a search engine's rendered-page tool.

Technical reference: Google's JavaScript SEO guide ↗

3. Write a title that identifies the work

Use a unique page title and heading. A practical format is Project or client — type of work — studio. Avoid labels such as “Project 04” and avoid stuffing every service into the title.

Add a short meta description that says what the project is and what your studio did. This is useful copy, not a list of keywords.

4. Decide what should be public

Include launched case pages in an XML sitemap and link to them from your work index. Keep embargoed or unfinished work behind authentication or on a private staging site. For a public draft that should not appear in search, use noindex—do not rely on robots.txt to hide it.

After launch, inspect the page in Search Console. A sitemap helps discovery but does not guarantee indexing.

5. Lead with images that are sharp and fast

Use a strong cover image, then enough supporting images to explain the system: applications, details, motion stills and process where relevant. There is no universal image count or pixel width; quality and purpose matter more than a fixed minimum.

Serve responsive image sizes, preserve a useful high-resolution source and use modern compression. Give meaningful images concise alt text. Decorative images should use empty alt text. Video can add depth, but it should not be the only way to understand the project.

Technical reference: Google's image guidance ↗

6. Explain the project in concrete terms

A compact case description should answer:

• Who was the client, and what was the brief?
• What did your studio make?
• What was your role and scope?
• When did the work launch?
• Who should be credited?
• Which typefaces, tools or collaborators were important?

Prefer facts to broad claims. Naming a typeface—“Set in Söhne by Klim Type Foundry”—is more useful than “distinctive typography.” Explicit credits also make the case discoverable in resources such as the D1S1 typeface index.

7. Connect the case to the rest of your site

Link the case from your main work index and relevant service or sector pages. From the case, link to related work and a clear contact route. Breadcrumbs help on larger sites. Use normal <a href> links so people and crawlers can follow them.

Add Open Graph metadata for social previews. Appropriate structured data can clarify the page, but it cannot compensate for thin or inaccessible content.

8. Treat the archive as a maintained product

Check old links, missing images and redirects after every redesign. Keep client names, credits and launch dates consistent. Make corrections visible quickly. A smaller reliable archive is more valuable than a large broken one.