Diagnosing Dreamweaver Site Cache Corruption: Phantom Links and Missing Files

The problem: phantom files and false broken links

If Dreamweaver's Files panel lists files that no longer exist on your disk, or the Link Checker reports broken links to assets that open normally in a browser, the local site cache is likely stale or corrupted. The useful takeaway: rebuild the cache first, but validate your site definition before assuming the problem is resolved. A cache rebuild fixes index corruption; it does not repair incorrect paths, cloaked folders, or server-side configuration errors.

Recognizable conditions

• The Files panel shows files that are not present in your operating system's file explorer or Finder.
• The Link Checker flags links to local files that exist and render correctly in a browser.
• The Related Files toolbar is empty or missing CSS, JavaScript, or server-side includes that are clearly referenced in the open document.
• Symptoms appear immediately after a Git branch switch, an operating-system file move, or a teammate's external changes.

Cause and diagnostic table

Observable condition	Probable cause	Diagnostic signal
Phantom broken links in Link Checker	Stale cache entries from external file operations	Link target exists in the local root folder but is absent from the Files panel
Ghost or missing entries in Files panel	Cache not refreshed after OS-level moves or Git checkout	File present in OS file explorer but not in Dreamweaver tree, or vice versa
Related Files toolbar failure	Incomplete cached dependency graph	Linked CSS or JS file exists on disk but does not appear in the toolbar
False positives after upload	Case-sensitivity mismatch or excluded folder	Link passes locally on Windows/macOS but fails on a Linux server

Ordered checks before you rebuild

1. Compare the Files panel to disk. Open your local root folder in Finder or File Explorer and note any files that appear in one location but not the other. This distinguishes cache ghosts from real deletions.
2. Verify the local root folder. In Site Setup, confirm the Local Site Folder points to the actual project directory. A trailing slash, symlink, or wrong parent path will produce persistent false positives.
3. Check excluded folders and cloaking. Dreamweaver can hide folders from link checking and the Files panel. Review the site's cloaking and exclusion settings; an excluded assets or includes directory will make valid dependencies look missing.
4. Inspect case sensitivity. Compare the exact filename case in your links against the names on disk. Windows and macOS are typically case-insensitive, while Linux servers are case-sensitive. A link that works locally may break on the server even if Dreamweaver's link check passes.
5. Test the Related Files toolbar. Open an HTML page with a known CSS or JavaScript link. If the toolbar does not populate, the cached dependency graph is likely incomplete.

Fixes tied to specific findings

Stale cache after external operations

If checks confirm ghost entries or phantom links, rebuild the site cache. In Dreamweaver, look for cache management options under the Site menu; the exact label varies by Creative Cloud release, so verify the menu text in your installed version. Rebuilding re-indexes links and dependencies. On very large sites this can take several minutes and may temporarily freeze the interface, so plan a maintenance window.

Risk: Do not manually edit or delete synchronization metadata files (such as _notes directories) while Dreamweaver is running. This can worsen cache inconsistency and corrupt remote synchronization state.

Incorrect local root folder

If the Local Site Folder is wrong, edit the site definition to point to the correct directory, then rebuild the cache. A cache rebuild alone will not resolve path errors.

Excluded or cloaked folders

Remove unnecessary cloaking or folder exclusions in Site Setup, then rebuild the cache so the dependency graph includes the previously hidden assets.

Case-sensitivity mismatch

Rename files or update links so the case matches exactly what the remote Linux server expects. This is a file-system fix, not a cache fix; rebuild the cache afterward so Dreamweaver records the corrected names.

Git branch switches and external moves

Dreamweaver does not always monitor external file-system events. After a Git checkout or branch switch, rebuild the cache before running link checks or relying on the Files panel.

Escalation criteria

• A cache rebuild and corrected site definition do not resolve phantom entries or false broken links.
• The remote server returns errors that are independent of Dreamweaver's cache, such as 404s for files that exist locally.
• Multiple team members experience identical symptoms, suggesting a repository-level or server-side issue rather than a local cache problem.
• Suspected corruption of synchronization metadata that persists after a standard cache rebuild.

Limitations and practical verification

Dreamweaver's cache behavior and exact menu paths have changed across Creative Cloud versions. Verify menu labels against your installed release before proceeding. A cache rebuild does not repair server-side configuration, incorrect absolute URLs, or permissions on the remote host.

To verify the result:

1. Run the sitewide link checker (typically found under the Site menu). Confirm that previously phantom broken links are resolved or correctly identified as external.
2. Compare the Files panel tree against the actual local root directory using your operating system's file explorer to identify any remaining missing or ghost entries.
3. Open a page with known linked CSS or JavaScript and verify that the Related Files toolbar populates correctly and allows navigation to the source file.
4. Upload a test page to the remote server and verify in a browser that server-side includes, image paths, and absolute links resolve correctly independent of Dreamweaver's cache.