Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
If index.html is uploaded but your new site still shows a welcome page, a 404, a 403, or a directory listing, the file is usually not being requested from the place or configuration you expect. The common causes are a wrong document root, the wrong virtual host, a missing default-document rule, a capitalization mismatch, or permissions that prevent the web-server account from reading the file. Test /index.html directly first; that single comparison tells you whether the problem is file mapping or directory-index handling.
What happens when you request the homepage
A browser request passes through several independent layers before a page is returned:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems
- DNS and the hostname: the hostname must resolve to the server that contains your site.
- Site selection: the request’s host name selects an Apache virtual host, an NGINX server block, or an IIS site. If it selects another site, you can see that site’s welcome page even though your file is present elsewhere.
- Path mapping: the selected site maps the URL to a filesystem directory. Apache calls this
DocumentRoot; NGINX usesrootoralias; IIS uses the site’s physical path. - Default-document processing: a request for
/names a directory, not a file. The server must be configured to chooseindex.html(or another default) inside that directory. - Filesystem access: the account running the web server must be able to traverse every parent directory and read the file.
A failure at any one of these layers can look like “the index file is missing.” The response code and the result of requesting the file by name identify the failing layer more reliably than repeatedly uploading the file.
Use the response to narrow the cause
| What you see | Most likely layer | First check |
|---|---|---|
| An old or generic welcome page | DNS or virtual-host/server-block selection | Confirm the hostname resolves to the intended server and that the request selects the site whose root contains your file. |
/index.html works, but / does not |
Default-document configuration | Check Apache DirectoryIndex, NGINX index, or the IIS default-document list and its order. |
| 404 Not Found | Path mapping or filename mismatch | Verify the active root, URL path, directory names, and capitalization. |
| 403 Forbidden | Access rules or filesystem permissions | Read the server error log and verify file-read and parent-directory traversal access. |
| IIS 403.14 | No available default document while directory browsing is disabled | Add or enable the intended default document instead of enabling a listing. |
| A directory listing | No selected default document and directory indexing enabled | Configure the intended index file; do not rely on directory listings for a homepage. |
Follow this diagnostic sequence
1. Request the file directly
- Open
https://your-hostname.example/(or the appropriate HTTP URL). - Open
https://your-hostname.example/index.html. - Compare the results.
If the second URL displays your page, DNS, the selected site, and the file’s path are probably correct. The remaining fault is the directory-index rule, its ordering, or a redirect/rewrite that affects the directory request. If both URLs fail, continue with the active-root and hostname checks before changing index settings.
#1 Best Overall
2. Confirm the active document root
Look at the configuration for the site that actually answers the request, not merely the default configuration or the directory used by your upload tool. The file must be physically below the active root:
| Server | Mapping to verify | What must be true |
|---|---|---|
| Apache | DocumentRoot |
index.html is inside the directory mapped by the selected virtual host. |
| NGINX | root or alias |
The URI /index.html resolves to the filesystem location where the file was placed. An alias can map a URI to a different directory than you expect. |
| IIS | Site physical path | The file is in the physical directory assigned to the site selected by the request’s host binding. |
When a control panel, deployment tool, or FTP client shows a folder named “public,” “www,” or “htdocs,” that name alone does not prove it is the active root. Confirm the path in the server’s site configuration.
3. Verify DNS and site selection
Creating a virtual host, server block, or IIS binding does not create DNS records. The hostname must resolve to the server’s IP address, and the request must include the hostname that the site configuration expects. If DNS still points to an old server, or if the host name does not match a configured site, the default site can answer with a welcome page or a different application.
Rank #2
- Used Book in Good Condition
- Test the exact hostname visitors use, including whether they use
wwwor the bare domain. - Compare the address reached by the hostname with the IP address assigned to the new server.
- If testing by IP returns a different page than testing by hostname, suspect host-based site selection rather than the file itself.
- Check every relevant binding or server-block name, including alternate hostnames that should redirect to the primary one.
Do not “fix” a wrong-site response by copying your file into the welcome-page directory. Correct the hostname mapping or site selection so future requests reach the intended root.
4. Match the path and capitalization exactly
Check the complete path, not only the final filename: index.html is different from Index.html when the server’s path semantics are case-sensitive, and /site/index.html is not the same URL as /index.html. Confirm spelling and capitalization of each directory as well as the extension. A file accidentally saved as index.html.html or uploaded into a nested directory will not satisfy a request for the root document.
5. Configure the default document
A root request succeeds only when the server’s ordered default-document mechanism includes the filename that exists in the mapped directory.
Rank #3
Apache
Apache uses DirectoryIndex. Configure the relevant virtual host or directory context to include index.html, then make sure another earlier entry is not selecting an unintended page. Apache’s documented behavior is that a directory request typically serves index.html when that file is configured as the directory index.
NGINX
NGINX uses the index directive. It defaults to index.html, but a server block, location, or included configuration can override that value or point the request at another root. Verify both the directive and the root/alias mapping used by the location handling /.
IIS
IIS uses an ordered default-document list. Microsoft lists Index.html among IIS defaults and IIS returns the first file in the list that it finds. Ensure the feature is enabled for the site and that the desired name appears in the list with the correct spelling. If no listed file exists and directory browsing is disabled, IIS can return 403.14.
After changing configuration, ensure the change is loaded by the active site. If the direct file URL works but the root still returns the old result, recheck which site configuration handled the request rather than assuming the edit affected the live site.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →6. Check permissions and traversal
The web-server account needs read access to index.html and permission to traverse every parent directory between the filesystem root and the file. Apache identifies filesystem permission failures as a common cause of Forbidden responses. As typical Unix examples, ordinary files may use mode 644 and directories mode 755, but the correct settings depend on the account, ownership, operating system, and security policy. Do not grant broad write access merely to make the page visible.
- Inspect the file’s owner and group and identify which account the web service uses.
- Check each parent directory for execute/traverse permission, not just the final directory.
- Review mandatory access controls, ACLs, or hosting-panel isolation if ordinary mode bits look correct.
- Use the server error log to distinguish a permission denial from a missing path.
7. Read the logs and classify the request
Make one request for / and one for /index.html while watching the access and error logs. Confirm the hostname, selected site, resolved filesystem path (when logged), status code, and any permission or configuration message. A 404 points toward mapping or naming; a 403 points toward access policy, permissions, or an unavailable default document; a successful direct request paired with a failed directory request points toward index selection. Logs are especially important when several sites share one server and their pages look similar.
Best Value
Server-specific failure patterns
Apache: the file is present but another index wins
Apache evaluates the configured DirectoryIndex names in order. If an earlier file exists, Apache can serve it instead of your index.html. A virtual host can also inherit a directory rule that differs from the global configuration. Check the active virtual host’s DocumentRoot, its effective DirectoryIndex, and any per-directory configuration that changes access or index handling.
Apache’s error log can identify both filesystem permission errors and configuration restrictions. A “Forbidden” response therefore requires checking access rules as well as Unix permissions.
NGINX: root, alias, and location matching matter
NGINX may have several location blocks. The block selected for / can use a different root or an alias than the block you expected. Confirm the effective block, then map /index.html to the exact filesystem path. If the file URL works but the directory URL does not, inspect the index directive and any internal redirect behavior associated with the location.
IIS: bindings and the default-document feature are separate
In IIS, the physical path can be correct while the request still reaches another site because the host binding, port, or protocol does not match. Once the correct site is selected, verify the Default Document feature and its ordered list. A directory request with no matching default file can produce 403.14 when directory browsing is disabled; enabling browsing may expose filenames, but it does not solve the missing homepage configuration.
Checks that prevent a false diagnosis
- Test both slash forms: compare
/and/index.htmlon the same hostname, protocol, and port. - Do not test only by IP: host-based configurations may deliberately return a different site for an IP request.
- Check redirects: a redirect can send the browser to another hostname or path whose site has a different root.
- Clear misleading browser state: verify the response with a private window or another client, but treat a persistent wrong page as a server-selection problem until logs prove otherwise.
- Inspect the deployed name: confirm that the server sees the same case and extension shown by the URL.
- Keep directory listings off for production: configure a real default document rather than exposing a file inventory.
A compact decision tree
- Does
/index.htmlload? If yes, fix the default-document rule. If no, continue. - Does the hostname reach the intended server? If no, correct DNS. If yes, continue.
- Does the hostname select the intended site? If no, correct the virtual host, server block, or IIS binding.
- Is the file inside that site’s active root? If no, deploy it to the configured path or change the site mapping deliberately.
- Does the name and case match? If no, rename the file or correct the URL.
- Is the response 403? Check access rules, file readability, and traversal permissions, then read the error log.
- Is the response still unexplained? Compare access-log entries for
/and/index.htmlto identify the exact site and path that handled each request.
What a correct deployment looks like
The hostname resolves to the new server’s address. Its request selects the intended site. That site’s DocumentRoot, NGINX root/alias, or IIS physical path contains a correctly named index.html. The web-server account can traverse the directory and read the file. Finally, the server’s default-document configuration includes that filename, so / and /index.html return the same homepage rather than two different results.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
