A sidebar is one of the oldest ideas in WordPress, and it is still useful. It gives you a column beside your content for search, recent posts, a contact box or an offer. You do not need a plugin to add one. WordPress already has everything you need. This guide shows you how to do it in both kinds of theme, what to check first, and how to fix it when the sidebar does not appear.<\/p>\n
The word sidebar is misleading. In WordPress it does not mean a column on the right. It means a named area that can hold widgets or blocks. Your theme decides where that area appears on screen.<\/p>\n
That is why some themes have a sidebar under the footer, and some have three of them. They are all sidebars as far as WordPress is concerned. The name is a leftover from the early days of blogging, when the area really was on the side.<\/p>\n
This matters because of how you add one. You are doing two separate jobs. First you create the area and give it a name. Then you tell your theme where to print it. Miss the second step and nothing shows up, even though the area exists.<\/p>\n
Once that clicks, the rest is easy. You are not hacking anything. You are using the same system your theme already uses for its own widget areas. Our guide to what WordPress widgets are and where to find them<\/a> covers the basics if this is all new to you.<\/p>\n The method you need depends on which kind of theme you run. There are two, and they work in completely different ways.<\/p>\n Go to Appearance<\/strong> in your dashboard and look at the menu. If you see an item called Editor<\/strong>, you have a block theme. These are the newer ones, built around full site editing. You design the whole layout visually, and there is no widget screen at all.<\/p>\n If you see Widgets<\/strong> and Customize<\/strong> instead, you have a classic theme. Most sites built before the last few years run one. Classic themes use the widget system, and that is where register code still applies. The WordPress Customizer<\/a> only appears on this kind of theme.<\/p>\n Check this before you write a single line. The two routes do not mix. Adding widget code to a block theme does nothing useful, and hunting for a Widgets screen in a block theme will only waste your time. If you are unsure, open Appearance<\/strong> and note exactly what is listed there.<\/p>\n Block themes make this the easier of the two. There is no code, and no registering. You build the column yourself inside the site editor.<\/p>\n Go to Appearance \u2192 Editor<\/strong>. Pick Templates<\/strong>, and open the template you want to change. For blog posts that is usually Single<\/strong>. For normal pages it is Page<\/strong>. Click the template to start editing it.<\/p>\n Find the block that holds your content. Select its parent group, then add a Columns<\/strong> block. Set it to two columns. Drag your existing content block into the wide column. The narrow column is now your sidebar.<\/p>\n Fill it with whatever you need. Search, Latest Posts, Categories, a Paragraph, an Image. These are the same tools the old widgets gave you, just as blocks. Resize the narrow column by dragging the divider, or set a width in the block settings panel.<\/p>\n Click Save<\/strong> when you are done. Your new column now appears on every page that uses that template. If you want the same sidebar in more than one template, select your column, open the block options and choose Create pattern<\/strong>. Tick the synced option. You can then drop that one pattern into other templates, and editing it once updates all of them.<\/p>\n Classic themes need a small piece of code. It goes in your theme\u2019s Before you touch any theme file, take a backup<\/a> or work on a staging site<\/a>. A typo in Put the code in a child theme<\/a>, not the parent. If you edit the parent theme directly, the next theme update wipes your work. A child theme keeps your changes safe.<\/p>\n Here is the code:<\/p>\n The name is what you will see in the dashboard. The id is what your template will call, so keep it short and all lowercase. The four markup lines control the HTML wrapped around each widget, which is what lets your CSS style them.<\/p>\n Save the file, then go to Appearance \u2192 Widgets<\/strong>. Your new area should now be listed. If it is not, check for a typo in the function name or a missing bracket.<\/p>\n Registering the area is only half the job. Nothing will show on your site until you tell a template to print it. This is the step most people miss.<\/p>\n Open the template file where you want the sidebar. For a blog post that is Add this where you want the sidebar to appear:<\/p>\n The id inside the quotes must match the one you registered. If they differ by even one character, nothing prints.<\/p>\n The check around it matters more than it looks. It asks whether the area has any widgets in it. If it is empty, the whole block is skipped and no stray markup reaches your page. That keeps your HTML clean and stops an empty box appearing in your layout.<\/p>\n Save, then reload a post. If your widgets show up, you are done. If the page looks the same, clear any caching you run and try again in a private window.<\/p>\n An empty sidebar does nothing, so the next step is putting something in it. Go to Appearance \u2192 Widgets<\/strong>. You will see your new area listed by the name you gave it.<\/p>\n Classic themes use the block interface on this screen now. Click the plus button inside your area and pick what you want. Search, Recent Posts, Categories and Custom HTML cover most needs. You can also drop in a plain Paragraph or an Image.<\/p>\n Think about what earns its place. A sidebar that lists everything helps nobody. One clear call to action, a search box and a short list of related posts will do more than ten widgets fighting for attention.<\/p>\n Styling comes from CSS. The class names you set in Keep the layout in mind on small screens. Most themes stack a sidebar underneath the content on a phone, which is usually right. Load your page on a real phone before you call it finished. If you ever need to move these settings to another site, you can export widget settings<\/a> rather than rebuilding them.<\/p>\n Most sidebar trouble comes down to a handful of causes. Work through these before assuming something is broken.<\/p>\n The area does not appear in the dashboard.<\/strong> The register code has not run. Check that the file saved, that the function name is unique, and that the The area exists but the sidebar does not show.<\/strong> The template is not calling it, or the id does not match. Compare the id in your register code with the one in It shows on posts but not on pages.<\/strong> You only edited one template. Single posts and pages use different files, so the code has to go in each one you want it on.<\/p>\n The sidebar drops below the content.<\/strong> This is a CSS width problem, not a WordPress one. We cover it in our guide to fixing a sidebar that falls below the content<\/a>.<\/p>\n Your theme already has a sidebar you do not want.<\/strong> You do not need new code at all. Removing a sidebar from WordPress<\/a> is a different job, and usually a quicker one.<\/p>\n The site goes blank after you save.<\/strong> That is almost always a PHP syntax error in You cannot find the file editor.<\/strong> Some sites hide it on purpose for security. Our note on a missing theme editor<\/a> explains why and what to use instead.<\/p>\n For a simple sidebar, yes. The code is short, it runs in a few milliseconds, and it has no settings screen to go stale. You are also not adding another thing to update or another possible conflict.<\/p>\n There is a fair case for a plugin in one situation. If you need many different sidebars shown by rule, such as one per category and another per product, a dedicated tool will manage that logic for you. Building that by hand takes real work.<\/p>\n For everything else, the code route is cleaner. It lives in your child theme, it travels with your theme, and anyone who knows WordPress can read it. The trade-off is that you need to be comfortable editing files, and you need a backup habit. If you are weighing the two approaches up, our comparison of functions.php against a small custom plugin<\/a> is a useful read.<\/p>\n One habit is worth keeping either way. Put your snippets in a child theme rather than the parent. That single decision prevents the most common cause of lost customisation, which is a theme update overwriting the file.<\/p>\n Adding a sidebar without a plugin comes down to a short checklist. Work out whether your theme is block or classic. In a block theme, add a Columns block in the site editor. In a classic theme, register the area in your child theme, then call it from the template file where you want it to show.<\/p>\n Take a backup before you edit anything, and keep the id consistent between the two pieces of code. Those two habits prevent most of the problems people run into.<\/p>\nCheck Your Theme Type Before You Start<\/h2>\n
How to Add a Sidebar in a Block Theme<\/h2>\n
How to Register a Sidebar in a Classic Theme<\/h2>\n
functions.php<\/code> file, and it tells WordPress that a new widget area exists.<\/p>\nfunctions.php<\/code> can lock you out of your own dashboard. Ten seconds of care here saves a long afternoon.<\/p>\n<?php\r\nfunction my_custom_sidebar() {\r\n register_sidebar( array(\r\n 'name' => 'My Custom Sidebar',\r\n 'id' => 'my-custom-sidebar',\r\n 'description' => 'Appears beside posts and pages.',\r\n 'before_widget' => '<div class=\"widget\">',\r\n 'after_widget' => '<\/div>',\r\n 'before_title' => '<h3 class=\"widget-title\">',\r\n 'after_title' => '<\/h3>',\r\n ) );\r\n}\r\nadd_action( 'widgets_init', 'my_custom_sidebar' );<\/code><\/pre>\nHow to Make the Sidebar Appear on the Page<\/h2>\n
single.php<\/code>. For a page it is page.php<\/code>. For the main blog list it is index.php<\/code>. Copy it into your child theme first if it is not there already.<\/p>\n<?php if ( is_active_sidebar( 'my-custom-sidebar' ) ) : ?>\r\n <aside class=\"my-sidebar\">\r\n <?php dynamic_sidebar( 'my-custom-sidebar' ); ?>\r\n <\/aside>\r\n<?php endif; ?><\/code><\/pre>\nFilling and Styling Your New Sidebar<\/h2>\n
before_widget<\/code> and before_title<\/code> are what you target. Add your rules to your child theme\u2019s stylesheet, or use Appearance \u2192 Customize<\/strong> to find the Additional CSS panel.<\/p>\nCommon Problems and How to Fix Them<\/h2>\n
add_action<\/code> line is present and spelled correctly.<\/p>\ndynamic_sidebar<\/code>, character by character.<\/p>\nfunctions.php<\/code>. Restore your backup, or rename the file over SFTP to get back in. Our guide to the WordPress critical error<\/a> walks through recovery.<\/p>\nIs Code Really Better Than a Plugin?<\/h2>\n
Getting Help With Your Theme<\/h2>\n