2 Geeks Web Design
A practical way to organise your website files
The best way to organise your website's file structure is to make it reflect how the business creates and publishes content, rather than how the designer happened to build it. A clear hierarchy helps locate assets quickly, prevents duplicate or outdated files, and makes it easier to transfer a website to another developer without confusion.
Good organisation is not about squeezing every file into fewer folders. It combines a logical directory hierarchy, predictable naming conventions, controlled access and dependable backups. The system should work for the people who publish ordinary updates, not only for the original developer who understands every detail of the build.
Australian small businesses benefit from a straightforward approach that suits local conditions. Australian English conventions, .com.au or .au domains, Australian-dollar invoices and communication between clients in Sydney, Melbourne, Brisbane and regional areas all shape the workflow. The structure should remain simple enough to maintain without dedicated technical staff.
Build the hierarchy around content and tasks
Begin by listing the main kinds of material the website uses: pages, images, documents, stylesheets, scripts, templates and downloadable files. Then arrange those materials according to their purpose and the way a team updates them. This creates a logical information architecture that extends beyond the design itself.
| Structure | Finding files | Ongoing maintenance | Best fit |
|---|---|---|---|
| Flat folder | Fast at first | Becomes chaotic quickly | Very small brochure sites |
| Grouped by file type | Predictable names | Can separate related assets | Simple static websites |
| Content-led hierarchy | Clear ownership and purpose | Requires consistent habits | Most business websites |
| Hybrid content-led structure | Scalable without excessive depth | Needs documented conventions | Growing sites and frequent publishing |
A useful content-led structure might place shared branding files together, product or service materials in their own areas, and editable page content inside the content management system. Shared resources are then easy to find without forcing every page to use the same rigid template.
The public URL structure should support the same logic. Clear paths such as /services/ or /resources/ help visitors and search engines understand where they are. For Australian businesses, the choice between a .com.au and .au domain should also be reflected in documentation, redirects and email accounts so the domain remains consistent across the website, invoices and online profiles.
Apply predictable file naming rules
Use lowercase letters, hyphens and short descriptive phrases. A file named team-photo-brisbane.jpg is easier to recognise than IMG_4827-final-new.jpg. Dates should use the year, month and day format, while versions belong in a content management system or version-control repository rather than being added to filenames.
Names should describe the subject and intended use. Include the stage of a creative asset only when it is genuinely useful, such as hero-image-wide.webp or case-study-acme-draft.png. Avoid sensitive information in filenames because URLs and shared links can expose them even after a file moves.
Redundant names such as final, new, copy and latest create uncertainty. They encourage people to upload another version instead of replacing the old one. A defined naming pattern, combined with folders for source material and approved exports, gives contributors a clear place for every file.
A simple handover guide can explain these rules in plain English. Australian clients often appreciate direct communication and a “no worries” attitude when an unexpected issue appears, but the underlying system should still remove guesswork. The handover document should include naming examples, approved locations and clear instructions for common publishing tasks.
Separate content, design and functionality
A small website may use folders such as assets/images, assets/documents, styles, scripts and templates. Larger projects can divide assets further by page, campaign or business unit. The key is to keep shared elements separate from files used by only one section.
Avoid organising the entire site by technical type alone. Large folders full of images, PDFs and videos make it harder to answer a practical question such as which file belongs on the Brisbane office page. Group those assets by content, then use labels or metadata to identify their format and status.
Keep editable source files separate from public delivery files. Working images, design drafts and third-party media should live outside the production directory unless they are intentionally published. A build process can then combine approved templates, scripts and assets into the final site without exposing development material.
Passwords, API keys and database details should never sit beside ordinary website files. Store them in a secure password manager or protected environment configuration. This separation reduces the chance of accidental disclosure when a directory is copied, shared with a contractor or uploaded during deployment.
Create a clear project archive
Not every file belongs in the live website. Keep a separate archive for briefs, contracts, research, design drafts, project notes and final deliverables. A practical project folder can distinguish between incoming material, working files, approved assets and handover records.
The R2-D2 build journal offers a useful example of disciplined project documentation. Its combination of electronics, mechanics, drive systems, photographs and written records shows how complex material can remain understandable when each component has a clear purpose and revision history.
The same principle suits agencies working between metropolitan and regional clients. A developer in Melbourne may collaborate with a business in Townsville, while a local freelancer in Perth might maintain sites for several organisations. Standardised archives make those handovers easier, even when the projects use different platforms and designers.
Final exports should be accompanied by a short index. Record what each delivered file contains, where it came from, which version is approved and whether anyone still needs access to the source material. This is especially valuable when a project spans months or several specialists rather than remaining with one person from start to finish.
Control access, versions and recovery
Give each contributor only the access required for their work. Editors may need to change page content, while a designer might require access to assets and templates. System settings, publishing tools and user management should remain restricted to trusted administrators.
Use version history wherever the platform provides it. For custom code, a repository such as Git records meaningful changes and allows an earlier version to be restored. Test major revisions in a staging environment before they reach the live website, particularly when a change affects forms, checkout functions or shared navigation.
Backups should include the website files, database and essential configuration. Follow the three-copy approach: keep one working copy, one local backup and one off-site copy. Australian conditions make off-site storage particularly sensible, since a local hardware failure should not be the only backup available to a business.
Customer information also needs deliberate protection. The Privacy Act 1988 and the Australian Privacy Principles provide important guidance for organisations handling personal information. Limit collected data, secure access to forms and administrative tools, and define how long records should be retained rather than leaving old files indefinitely in shared folders.
Make maintenance part of the structure
A structured site still needs regular attention. Set aside time to check broken links, missing images, outdated copyright details and files that no longer appear on the site. Remove superseded exports and archive completed projects, but retain the approved version and any records required for legal or operational purposes.
Review the directory structure after major redesigns or when the business adds a new service area. Compare the live navigation, content management categories and stored assets so they continue to describe the same organisation. This prevents the file system from drifting away from the website as both evolve.
Optimisation should be built into the routine. Large photographs, uncompressed documents and unnecessary scripts can slow pages for visitors using fixed wireless, regional NBN connections or mobile data. Compress approved images, retain appropriately sized versions and record the dimensions needed by each template.
A well-organised website remains calmer to edit, safer to hand over and quicker to maintain. For a small business, that reliability supports everything from its Google Business Profile and .com.au email to the customer forms and Australian-dollar services presented on each page. Clear folders, disciplined names and sensible maintenance practices give the site a foundation that can keep working long after launch day.