Child Themes and functions.php: Where SEO Code Lives

If you write SEO logic into a theme's functions.php file, the logic stops the day you switch themes, and nothing on the screen tells you. Short answer: put anything that must keep working whatever the site looks like into a plugin, keep look-and-feel changes in a child theme, and never edit the parent theme's files in place. The WordPress theme documentation draws exactly that line. If you add small snippets to your own site, or maintain such snippets on client sites, the rule set in this article applies to you.

A theme file is the wrong home for site-wide search logic

The WordPress page on theme functions (Opens in a new tab) describes functions.php as a file that behaves like a plugin: it can call WordPress functions and define your own. The same page then makes a distinction that matters here. For features that should work regardless of how the site looks, it says it is best practice to put them in a plugin. A plugin runs whenever it is active, whatever theme is selected. The functions.php file belongs to one theme only, and if the theme changes, the page says the features can no longer be used.

Think about what that means for search. Title tag rules, canonical logic, structured data, noindex conditions and redirect lists describe your content and your crawl settings. None of them describe the colour of a button. Tying them to a theme links a design choice to your search visibility.

The moment of the theme switch

Only the active theme's functions.php runs. The moment you activate another theme, the old file is no longer loaded, and every function, hook and addition in it goes quiet. No error appears. The output that used to arrive simply stops, and unless somebody compares page sources, the loss can go unnoticed for weeks.

A single test for any snippet

Practical suggestion: for every snippet, ask whether it should keep working if the site's appearance changed completely. If yes, it belongs in a plugin. If it only registers this theme's menu locations or image sizes, it can stay with the theme.

If you use a translated admin interface, screen names may differ from the English labels used here.

Five questions to ask first

1. Is this code still needed after a theme switch? If yes, it goes into a plugin.
2. Does the function name carry a unique prefix? The documentation recommends prefixes to avoid clashes between functions, classes and variables.
3. Does another source, such as an SEO plugin, already produce the same output?
4. Does the block hook into theme support? If so, it can stay in the theme's file.
5. Is a copy of the old block saved for rollback?

How a child theme works, and where it stops

The WordPress child theme documentation (Opens in a new tab) calls a child theme an extension of a parent theme. It lets you change the look or behaviour of a theme without editing the parent's code, from small colour tweaks to extensive overrides. Because your changes sit in the child, the page says, the parent can be updated without losing them.

Required file in a child theme

The only file a child theme must have is style.css. Its header needs a Template field naming the parent, and the value must match the parent's folder name exactly. In the documentation's example, Twenty Twenty-Four lives in the twentytwentyfour folder, so that is the Template value. A typo in that field and the child cannot find its parent.

Load order of the two functions.php files

A child's functions.php does not replace the parent's. Both load, and the child's file loads right before the parent's. That is why you should not copy the parent's functions into the child: two functions with the same name cause a fatal error. The theme functions page says the same from another angle: a child file does not override the parent's, though it can add to it or replace functions. It also advises theme developers to give function names a unique prefix, using myfirsttheme_ as its example.

Loading the child theme's stylesheet

Whether the child's stylesheet loads by itself depends on how the parent is written. The documentation describes loading stylesheets with wp_enqueue_style hooked to wp_enqueue_scripts. If the parent loads neither its own nor the child's style.css, as in the Twenty Twenty-Four example, you enqueue the child stylesheet in the child's functions.php. If the parent loads only the active theme's stylesheet, you may need to enqueue the parent's stylesheet explicitly too. After any change, open the front end and confirm that the styles arrived.

What a child theme does not protect

The documentation notes that very large customisations can make a child theme hard to manage, and suggests forking the parent into a full theme in that case. A child theme also depends on its parent. Choose a new parent theme and the old child no longer applies. So a child theme answers update loss; it does not answer loss on a theme switch.

Assumptions to check before you trust them

The first misreading is that a child theme's functions.php replaces the parent's. The child themes page says the child's file loads immediately before the parent's and does not override it. The second is that code stored in a theme keeps working after a switch. Only the active theme's file runs, so it stops. The third is that code moved into a plugin loads alongside the theme file at the same moment. The theme page says functions.php loads after any plugin files have loaded. If both places print the same tag, both can run, which is how double output appears.

Two ways code gets lost

People mix up the two failures. Both end in missing code, but the causes and the cures differ.

The last two rows remind you that moving code into a plugin is not loss-proof either. If the plugin is not recorded, an administrator can take it for clutter and delete it.

Auditing what your functions.php does today

Before moving anything, read the file. The theme functions page lists examples such as hooking into WordPress filters, such as changing excerpt length, enabling features with add_theme_support, and defining functions to reuse across templates. Sort every block you find into one of these groups and then ask which of them touches search.

• Filter hooks change output. Those that alter titles, excerpts or content can matter for search.
• Theme support calls enable features such as thumbnails, menus and post formats. They belong to the theme, and block themes enable some of them automatically.
• Helper functions serve templates. They disappear with the templates.

Practical suggestion: write one line per block saying what it does and which page types it touches. That list is the raw material for the move, and it doubles as documentation for whoever inherits the site.

Sorting audit findings by home

The functions.php documentation says the file behaves like a plugin, yet only the active theme's file runs. The same page names a plugin as the best practice for features meant to work regardless of how the site looks. Two facts give you a working classification. Practical suggestion: label each block in your audit with a category from the classification table.

A decision rule: theme, child theme or plugin

Three questions cover every snippet.

1. Must the code keep working when the theme changes? If yes, it goes in a plugin.
2. Does it only change this theme's look or templates? If yes, it goes in a child theme.
3. Is it sitting in the parent theme's files? If yes, move it to a child theme or a plugin; do not leave it there.

When the answers conflict, because a snippet touches both look and search behaviour, split it. The look part stays in the child theme and the search part goes into the plugin.

Custom plugin or ready-made plugin

Putting code in a plugin does not mean writing your own. Both routes fit the plugin model the documentation describes: its own header, a place under wp-content/plugins, and activation that makes it work in every theme.

Practical suggestion: check whether a plugin setting already solves the need before writing code. Code carries a maintenance burden: after each WordPress or PHP version change, you are the one who has to confirm it still works.

Contents of a small custom plugin

The top of the file holds the plugin's name, description and version. Those details show in the plugin list and become the source of your inventory record. Inside, each function starts with the unique prefix and each rule carries a short note explaining why it exists. That note helps the person who reads the code six months later understand a rule before deleting it. Keep each plugin to one purpose. A title rule, a redirect list and a visual tweak in the same file make it hard to tell which part is at fault when something breaks.

Many sites, one maintenance plugin

If the same small snippets run on many client sites, one maintenance plugin is easier to update than the same code pasted into each theme. When you hand over a site, state in writing which code sits in the plugin and which in the child theme, so it is clear who moves what in a future theme change. For the wider settings picture, see the WordPress SEO settings checklist. Load order and child theme behaviour can differ by WordPress version and theme type; check the current documentation pages before relying on them.

Moving the code into a plugin

Moving is more than cut and paste. Practical suggestion: work through these steps in order.

1. Take the inventory from your functions.php audit.
2. Mark each block as theme-independent or theme-bound. Only the independent ones move.
3. Back up the site and build a staging copy.
4. Create a new plugin file. The documentation says a plugin needs its own header and lives under wp-content/plugins.
5. Rename functions with a unique prefix that identifies your site.
6. Activate the plugin on staging while leaving the old code in functions.php, and look for double output.
7. If nothing doubles, remove the old code from functions.php and compare the output with your earlier record.
8. If everything matches, repeat the steps on the live site after a fresh backup.

Duplicate output

Leave the same code in the theme and in the plugin and it runs twice: two title tags, two canonicals, two redirects. When a title tag or canonical appears twice, it is unclear which one represents the page. That is why step six asks you to search the front-end source for any repeated tag.

Prefixes and name clashes

The theme functions page says that functions, classes or variables sharing a name can cause errors and that avoiding it is the shared responsibility of theme and plugin developers. Give every function you move a short prefix tied to your site. A function with a generic name can collide with a function in another plugin or theme and take the site down.

When the load order shifts

The page also states that functions.php loads after the plugin files. So moving code into a plugin can change when it runs. If a snippet depends on something another component defines, it may stop working after the move. The usual remedy is to attach it to a suitable hook, though the right hook depends on the snippet and the documentation offers no single rule. That is why checking the output after the move is not optional.

Rehearsing a theme switch

If you plan to switch themes, read the old functions.php before you do. Each block in it is a possible SEO loss that the new theme will not carry. Practical suggestion: save the source of five pages before and after the switch and compare them. The pages can be the home page, an article, a category page, a search result and a 404 page. If the title tag, the canonical, the robots meta tag or the structured data lines differ, go back to the old file to find the missing code. For address structure changes caused by the switch, apply the checks in URL structure and slug best practices.

Example scenario: an independent cinema's website

Example scenario: an independent cinema's site has grown for years on small snippets written by different people. The parent theme's functions.php holds a title rewrite, a redirect list for old film pages and a custom post type for screenings. The cinema wants to move to a new theme and starts by listing the code.

When the move is done, the cinema records the plugin in its inventory, names an owner and archives a copy of the old functions.php. A year later, where the code went and why is still readable.

Example scenario: a regional museum's blog

A museum blog plans a theme change. The old functions.php holds three jobs: a title format, a description tag for category archives and a thumbnail size. After classification, the first two move to a plugin and the third goes into the new theme's own file. The order of work is simple: install and activate the plugin, switch off the matching block in the old theme, compare the page source, and only then switch themes. Seeing the same tag twice during that comparison is the double-output signal. This scenario is fictional.

Mistakes to avoid during the move

Backup, version record and rollback

Before any move, back up the theme folder and the database. If trouble follows, you can deactivate the plugin and put the old code back in functions.php to return to the earlier state. That route works only if you have the backup and a copy of the old code. Practical suggestion: archive the old code, dated and with a reason, instead of deleting it. Remembering deleted code always costs more than reading kept code.

What a rollback cannot undo

Deactivating a plugin does not return output to its old state at once, because a cache may still serve the previous version. Clear the cache after a rollback and read the source again. Settings that a plugin wrote to the database do not vanish with it, so if the plugin saved settings permanently, review them as well.

Pre-move checklist

When you review extra code on your site:

• Is any code written straight into the parent theme's functions.php or template files
• Which part of it must work independently of the theme
• Does that part live in a plugin or in the theme
• Do function names carry a unique prefix
• Does the Template field in the child's style.css match the parent folder exactly
• Do the child's styles actually load
• Is the plugin recorded with an owner and a reason
• Were five page sources compared before and after the move

Frequently Asked Questions

What happens if SEO code stays in functions.php?

If the theme changes, that theme's functions.php no longer runs and the code goes quiet. The WordPress theme documentation names a plugin as the best-practice home for features that should work whatever the site looks like.

Does a child theme protect against a theme switch?

No. A child theme depends on its parent, so changing the parent leaves the child useless. A child theme is the answer to losing changes when the parent theme updates.

Does a child theme's functions.php override the parent's?

No. According to the documentation both load, and the child's loads right before the parent's. Copying the parent's functions can cause a fatal error from duplicate names.

Which file is required for a child theme?

Only style.css. The Template field in its header must match the parent theme's folder name exactly.

Does moving code into a plugin change when it loads?

Yes, it can. The documentation says functions.php loads after the plugin files. If your snippet depends on another component, check the output after the move.

Is there a ready-made code sample for this?

The documentation covers unique function prefixes and the plugin header, but no ready-made SEO snippet is offered here. Judge each site's code against its own inventory.

Conclusion

Code that touches search belongs in a layer that a theme change cannot reach. The WordPress theme documentation names a plugin as the best-practice home for features that should work whatever the site looks like, and it presents a child theme as the way to keep changes when the parent updates. For each snippet, ask whether it must survive a theme change, record it in an inventory, and compare page sources before and after every move.

With the code in the right place, what remains is setting the site's address settings correctly.

For a steady flow of carefully made articles, take a look at our content writing service.