Every time WordPress serves a page, it has to decide which of a theme's template files should render it. That decision isn't random or configured anywhere — it follows a fixed, predictable search order called the template hierarchy, and understanding it is what turns "a folder of PHP files" into a theme that actually knows what to show where.
For any given request, WordPress works out what's being asked for (a single post? a category archive? the homepage?) and then checks for a series of increasingly generic file names, in order, using the first one that actually exists in the theme. If none of the specific ones exist, it always falls back to index.php — which is exactly why that file is the one truly required template.
| Requested URL | Files checked, in order |
|---|---|
| A single blog post | single-{post-type}.php → single.php → index.php |
| A standalone page | page-{slug}.php → page-{id}.php → page.php → index.php |
| A category archive | category-{slug}.php → category-{id}.php → category.php → archive.php → index.php |
| A 404 (not found) | 404.php → index.php |
| The site's homepage | front-page.php → home.php → page.php (if a static page is set) → index.php |
This is what makes it possible to give one specific page — a single category, a single page, even a single post — its own completely different layout, just by adding a more specifically-named file. No settings screen, no conditional logic inside a shared template required; the file name alone tells WordPress when to use it.
This is the pattern, not the full list
The full hierarchy covers many more cases than the table above — tag archives, author archives, date archives, search results, and every custom post type and taxonomy gets its own equivalent chain. The official WordPress template hierarchy diagram is worth keeping bookmarked; this lesson covers the pattern, not every single branch.
With the decision-making logic clear, the next lesson builds the actual files this hierarchy points to most often — index.php, page.php, single.php, and 404.php.