How to Organize Website Assets Across Multiple Projects
Use projects, folders, readable filenames, tags, and alt text to build a website asset library that stays understandable as products and teams grow.
The most durable way to organize website assets is to make ownership visible at every level. Start with a workspace, give each site or product its own project, use folders for durable categories, choose readable filenames, and add metadata for the information that should not live in a URL.
This structure scales better than one enormous media folder because developers, collaborators, APIs, and public paths all use the same model.
The recommended hierarchy
Use four layers:
workspace / project / folder / filename
For example:
acme / marketing-site / brand / logo-dark.svg
acme / marketing-site / articles / dam-guide.webp
acme / docs / screenshots / api-key-dialog.webp
acme / mobile-app / store / app-preview.png
In Stashr, every upload must belong to a project. The workspace slug is the first public-path segment, followed by the project slug, folder path, and filename.
| Layer | Use it for | Example |
|---|---|---|
| Workspace | Account or organization boundary | acme |
| Project | Site, product, client, campaign, or environment | docs |
| Folder | Stable functional grouping | screenshots/onboarding |
| Filename | Specific asset identity | create-api-key.webp |
| Metadata | Human description and flexible discovery | title, alt text, tags |
Make projects reflect deployment ownership
A project should answer: “Which product is responsible for this asset?”
Good project boundaries include:
- a public marketing site;
- a documentation application;
- an iOS or Android product;
- a client site managed by an agency;
- a campaign with its own delivery lifecycle;
- a separate environment where isolation matters.
Avoid creating a project for every temporary folder or asset type. Images, PDFs, and Videos are usually folder or metadata concerns, not product boundaries.
Also avoid putting every company asset into one project merely because they share a brand. A logo used by several products can live in a deliberate shared-brand project, or each product can own the exact export it uses. Choose one policy and document it.
Stashr plans currently include one project on Free, five on Hobby, and unlimited projects on Pro. Check the live pricing section before designing a large workspace around those limits.
Choose project slugs carefully
Project slugs appear in public asset URLs and cannot be changed in Stashr. Treat them like stable route segments.
Prefer short, descriptive names:
website
docs
ios-app
client-portal
spring-launch
Avoid dates unless the project genuinely belongs to a dated campaign. Avoid internal codenames when external URLs should remain understandable. Do not include a technology name such as next-site if the product may outlive that implementation.
The workspace slug is also locked after setup because it forms the first URL segment. Choose an organization or enduring account name rather than a temporary project label.
Build folders around retrieval
Folders should help someone predict where an asset lives. A practical website project might use:
brand/
articles/
product/
screenshots/
social/
press/
downloads/
video/
Add depth only where it improves retrieval:
screenshots/onboarding/
screenshots/billing/
articles/dam-comparisons/
downloads/data-sheets/
Deep taxonomies are expensive to remember and maintain. If a category changes frequently or an asset belongs to several themes, use tags instead of forcing the information into one folder path.
Stashr rejects unsafe folder paths with leading or trailing slashes, empty segments, backslashes, and dot segments. Moves update the asset's stored path, so moving a publicly used asset is a real URL change and should be reviewed accordingly.
Give filenames a job
A filename should identify the asset without carrying every piece of metadata.
Good filenames are:
- lowercase where practical;
- hyphenated and readable;
- specific enough to distinguish related exports;
- free from temporary review language;
- stable after publication.
Prefer:
api-key-dialog.webp
developer-dam-comparison.webp
pricing-overview.pdf
ios-app-preview-01.png
Avoid:
IMG_4832.png
final-final-v3.png
new-hero-use-this-one.jpg
Screenshot 2026-08-05 at 09.14.52.png
Do not put mutable facts such as “approved,” owner names, or campaign status into filenames unless the file is a deliberate immutable export. Use metadata and workflow documentation for that information.
Use metadata for human meaning
Stashr assets support a human-friendly title, image alt text, and tags.
Titles
Use the title people should see in the library:
API key creation dialog
The title can be clearer and more natural than the filename without affecting the public URL.
Alt text
Store a useful description of the image subject:
Stashr settings panel showing a newly created API key
When the image is placed on a page, review the final HTML alt for that context. A decorative image should usually have empty alt text, while an informative screenshot needs a description of what the reader should learn.
Tags
Use tags for facets that cut across folders:
onboarding
dashboard
documentation
dark-ui
2026-launch
Keep a short controlled vocabulary. Singular and plural duplicates, unexplained abbreviations, and near-identical tags make search less useful.
Separate sources from delivery-ready exports
Not every working file belongs in the public product library. Design sources, layered project files, review exports, and raw captures may remain in the creative workspace. The DAM should contain assets that need product ownership, metadata, API access, or delivery URLs.
Stashr can retain original images alongside optimized variants when the workspace or individual upload chooses that option. This is useful when the original is needed for future delivery sizes. It is not a replacement for a full creative-source workflow or version history.
Decide whether your library stores:
- only final delivery assets;
- originals and optimized image variants;
- downloadable source documents intended for customers;
- internal working files on paid plans.
Apply the rule consistently by project.
Design public paths before uploading
Because the project slug, folder path, and filename form the URL, sketch important paths in advance:
/acme/website/brand/logo-dark.webp
/acme/website/articles/what-is-a-dam.webp
/acme/docs/screenshots/api-key-dialog.webp
Readable URLs improve code review and support conversations. They also create a contract. Moving brand/logo-dark.webp into archive/ changes the public path. Stashr does not currently provide automatic redirect management for moved assets.
For an application-facing library, prefer a little planning over frequent path churn.
Organize API integrations by responsibility
Create separate API keys for separate integrations. A documentation build, CMS connector, and internal uploader should not all share the same credential.
Use assets:read when an integration only discovers and retrieves metadata. Use assets:write when it must create, upload, move, update, or delete DAM resources.
Keys belong to the workspace and must remain server-side. Name them after the integration so one can be revoked without breaking unrelated systems.
The API-key guide covers storage and scopes, while the upload guide describes multipart metadata and returned URLs.
A migration workflow for an existing asset mess
Do not begin by copying every file into a new tool. Begin with one active product.
- Inventory the assets actually referenced by the product.
- Identify owners and remove obvious duplicates outside the live set.
- Create one Stashr project with an enduring slug.
- Define a shallow folder structure.
- Rename files to readable stable names.
- Add titles, alt text, and a small tag vocabulary.
- Upload and record the returned delivery URLs.
- Replace references in a controlled release.
- Verify the real pages before removing old sources.
- Repeat for the next project using the lessons from the first.
Keep rollback paths during migration. A clean library is not worth broken production images.
A maintenance checklist
- Every asset belongs to a clear project.
- Folder depth remains understandable to a new teammate.
- Filenames describe assets without temporary status words.
- Titles and alt text are useful, not copied blindly from filenames.
- Tags follow a small vocabulary.
- Unused API keys are revoked.
- Moves and renames are reviewed as URL changes.
- Storage and delivery usage are checked around launches.
- Obsolete assets are removed only after usage is understood.
Good digital asset organization is less about perfect taxonomy and more about durable ownership. Projects establish the boundary, folders establish the neighborhood, filenames establish identity, and metadata adds flexible human meaning.
Read what a DAM means for developers, compare a DAM with shared drives, or start a Stashr workspace with one product and build the structure from real assets.