Choose WordPress widgets by checking the active theme, the area where each widget will appear and the task it helps a visitor complete. For a classic-widget site, record both the widget’s provider and its placement before changing themes. Then test the resulting page with keyboard navigation and a narrow screen, rather than accepting the editor preview alone.
The term “widget” can describe different editing experiences. The widget management article explicitly covers classic widgets. Its instructions should therefore be applied to a matching installation, not assumed to describe every block theme. Identify the actual editing screen first and write its name in the handover record so a later editor can follow the correct route.
What determines where a widget appears?
The theme determines the available widget areas. The WordPress management guide explains that those areas often appear in sidebars or footers, but their placement varies. A business requirement such as “show contact details beside every article” should be checked against the active theme’s actual areas and page layouts.
A classic widget is a PHP object that outputs HTML. The same kind of classic widget can appear several times on one page. The classic-theme developer handbook describes those building blocks. This means a duplicated contact block may represent separate configured instances, rather than one shared item that will update everywhere.
Inspect representative pages before making a placement decision. A sidebar that works beside a short article may become awkward beside a long guide. On a phone, the same content needs a sensible position in the reading sequence. Record the desired location in words as well as on a screenshot: “after the article and before related links” is clearer than “near the bottom”.
What changes when the theme or plugin changes?
A widget supplied by a theme is available only while that theme is active. A plugin-provided widget can remain available when the user changes themes. These documented differences make the provider an essential field in a widget inventory. A theme replacement and a widget replacement are related decisions, but they are not automatically the same job.
Classic widgets can save their data in the database options table. Record the configuration that matters to the business, including titles, destination links and selected content. Database storage is not a substitute for a readable placement plan. The person reviewing a new theme still needs to know which public pages should contain each item.
Moving a classic widget to Inactive Widgets retains its settings for possible reuse. Use that documented option when the intended change is temporary removal rather than permanent disposal. Check the result in a test copy and keep a record of the original area; a saved configuration alone does not explain where the widget belongs after a redesign.
For the broader replacement decision, see theme fit and migration risks. Keep this review focused on the widget instances, their areas and their public behaviour, so the task does not expand into an unplanned site rebuild.
| Inventory field | Example entry | Question it resolves |
|---|---|---|
| Visitor task | Find the enquiry link | Does this widget have a useful purpose? |
| Provider | Named theme or plugin | What must remain available? |
| Instance | Article contact block | Is this separate from the footer instance? |
| Current area | Article sidebar | Which layout controls placement? |
| Required mobile position | After article text | Is the reading order intentional? |
| Removal treatment | Move to inactive area | Should settings be retained? |
| Acceptance evidence | Page and keyboard checks | Has the real output been reviewed? |
How should accessibility be checked?
Classic Widgets accessibility mode offers Add and Edit buttons instead of drag and drop. That is an editing-screen control documented by WordPress. It does not by itself establish that the resulting public widget is accessible. Review the administration task and the visitor task separately.
The widget area defines the HTML wrapper tags around its widgets. Ask the developer to inspect the actual output when a title appears at the wrong heading level or repeated sections become hard to navigate. Changing the visible wording may be insufficient if the surrounding structure is the cause of the problem.
Use a keyboard to reach every interactive element in the widget. Check that focus is visible, links have understandable names and a form does not require a mouse to complete. Read the page headings in sequence and enlarge the text. These are proposed acceptance checks for the actual site; a familiar widget name should not exempt it from review.
Avoid adding a widget just to fill an empty column. A repeated list of irrelevant links can distract from the page’s purpose. Ask what the visitor gains at that point in the journey and remove items whose role nobody can explain. A smaller, well-placed contact option may serve the reader better than several competing panels.
Original widget relocation rehearsal
Use this hypothetical exercise for a small membership organisation replacing a classic theme. Its article pages currently contain a search widget, a contact widget and a long archive list. The original artefact is a placement and continuity register with one row per instance, supported by a before-and-after page sample.
Start with the task. The search widget helps readers locate another guide. The contact widget takes them to an enquiry route. The archive list has no agreed owner or clear purpose. Record that uncertainty rather than automatically copying all three items into the new layout. Ask the content owner whether a shorter, maintained navigation route would better serve readers.
Trace the provider. Identify whether each required widget comes from WordPress, the theme or a plugin. In the test copy, compare the new theme’s available areas with the register. If a required theme-specific widget disappears, record a replacement requirement and inspect the proposed replacement before removing the old theme from the plan.
Rehearse relocation. Place the contact instance in the intended new area and check a short article, a long article and an article without a featured image. Record its desktop position and mobile reading position separately. Then edit its contact text and confirm whether the footer instance changes; update the register to reflect the observed relationship.
Test temporary removal. Move the archive widget to the inactive area, inspect the public pages and record the retained configuration. Have the content owner judge whether navigation remains useful without it. This gives a reversible design decision a concrete test rather than turning the redesign into a debate about empty space.
Complete the acceptance row. Attach the relevant page samples, keyboard observations and unresolved defects. Mark each required instance retained, replaced or intentionally removed. An unexplained missing widget remains an open issue even if the new homepage looks finished.
What should an editor receive at handover?
Provide the final register, the correct editing route and a short explanation of which items are shared and which are separate instances. Include a named owner for content that changes, such as office hours or contact links. A technically working widget can still mislead readers when its information is left unowned.
Use the backup and restore guide when planning the wider recovery arrangements for a theme change. For a focused brief, see WordPress services and get started with the widget inventory, desired placements and the visitor tasks that must remain usable.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.