If you manage articles on several WordPress sites, keep one reliable record for each post: where it lives, which source it came from, and what needs attention next. Then use a suitable way to reach each destination and check the result there. That record helps you find and maintain posts; publishing the same content to multiple sites is a separate job.
The simplest way to stay oriented is to treat each post on each site as its own item. A shared headline does not prove two posts are the same version, and changing one post does not establish that another has changed too. Record each destination, decide which details should match, and close an update only after checking the relevant public page or pages.
Start with the job: find posts, update them, or synchronize copies
“Manage posts across WordPress sites” can mean three different tasks. You may need to locate an article, revise an existing article, or distribute and maintain related content on more than one site. Separate those jobs before choosing a tool or building a process.
| Your task | What you need | A useful completion check |
|---|---|---|
| Find an article | A record connecting its title to the correct site and public URL | The URL opens the intended article on the intended domain |
| Revise an existing article | The destination, its existing editor entry, and a source or change note | The public page shows the correction you meant to make |
| Publish or update related content | A decision about shared text, site-specific details, and whether a synchronization method is being used | Each affected destination has a recorded result |
This article focuses on editorial work on posts. Looking after the sites themselves is a different responsibility. For example, WordPress management guides may cover site-level work such as updates and administration; that work does not, by itself, identify which version of an article needs an editorial correction. Keep those lists separate if the same person handles both.
The post record answers “Which article, on which site, from which source?” Access tools answer “How do I reach that site or content?” Crossposting and synchronization tools address a third question: “How is related content sent to or coordinated across destinations?” A tool that helps with one question should not be assumed to solve the others.
Choose between site switching, a central post view, and crossposting
Choose the lightest approach that covers your actual work. If you make occasional edits, a register and access to each site may be enough. If you often need to find articles across sites, a central post view may help with discovery. If you need related posts to be sent to more than one destination or kept aligned, assess a crossposting or synchronization option specifically.
| Approach | Useful when | What to establish before relying on it |
|---|---|---|
| Switch between sites and use a register | You manage a modest set of posts and edits are occasional | Someone must keep the record current; it does not itself coordinate copies |
| Use a central post view | Finding or reviewing posts across sites is frequent | Check which sites and post details it includes, and whether it supports the specific editorial task you need |
| Use a site-management dashboard | You also need a shared place for supported site-administration work | Confirm its scope; a site-management view is not automatically an editorial record or a content-sync method |
| Use WordPress Multisite | Your sites are intended to operate within a shared WordPress network | Confirm that a network fits the sites’ ownership and operating needs; it is not a substitute for recording post sources and destinations |
| Use crossposting or synchronization | You deliberately send or coordinate content across destinations | Check whether the chosen tool handles new posts, existing posts, later edits, and the fields you care about |
WordPress.com documents account-level ways to manage and switch among sites. That may help with access when your sites are managed through that account, but it does not answer whether two article versions share content. WordPress Multisite is a network setup for multiple sites; consider it when that network arrangement fits your sites, not merely because you want a list of posts. See WordPress.com’s account and site management guide and the overview of WordPress Multisite management for those distinct site-level approaches.
Crossposting is a more specific capability. For example, the Simple WordPress Crossposting documentation describes sending posts to multiple sites and syncing content between sites. Treat that as a feature of the named tool, not a general behavior of every dashboard, WordPress setup, or editing action. Before relying on any tool, check its documentation and configuration against a low-risk post: does it create a new post or act on an existing one, which fields does it handle, and what happens after a later edit? If you cannot establish the answers, keep the destinations as separately managed versions and check each one.
A practical selector is simple: if your question is “Where is this post?”, improve the register or find a suitable cross-site view. If it is “How do I edit this post?”, confirm the destination and existing post entry. If it is “How do I keep related copies aligned?”, evaluate a method that explicitly supports that behavior and plan how to check each result.
Build a cross-site post register
A post register is an editorial recommendation, not a special WordPress feature. A spreadsheet or another shared list can work. Give each site-specific post its own row, even when two rows refer to related versions. That way a similar title cannot cause you to mistake one destination, source, or status for another.
Use fields that let someone locate the post, understand its provenance, and decide what happens next. The site name and domain distinguish destinations. The public URL identifies what readers can open. A direct edit URL is useful when available, but it does not replace the public URL. The source reference points to the document, brief, or correction note that should guide the work. Status, owner, verification date, and next action keep the record operational rather than merely descriptive.
The sample rows below are hypothetical. The names, domains, URLs, posts, people, dates, and editorial decisions are illustrative, not real sites or publishing results. The Northline Journal and Field Notes entries have similar titles, but they are separate records on separate domains.
| Site name and domain | Post title | Published URL | Edit URL, if available | Source reference | Status | Responsible editor | Last verified | Next action |
|---|---|---|---|---|---|---|---|---|
| Northline Journal — northline.example | A Guide to Balcony Herbs | https://northline.example/balcony-herbs/ | https://northline.example/editor/post-241/ | Docs: balcony-herbs-v3 | Published; correction pending | Mira | 2026-10-12 | Correct watering sentence; review Field Notes version |
| Field Notes — fieldnotes.example | A Guide to Balcony Herbs | https://fieldnotes.example/growing-herbs-in-pots/ | https://fieldnotes.example/editor/post-88/ | DOCX: herbs-pots-approved | Published; local version | Dev | 2026-10-09 | Compare shared watering sentence; retain local CTA |
| Studio Ledger — studioledger.example | Preparing Balcony Pots for Planting | https://studioledger.example/balcony-pots/ | https://studioledger.example/editor/post-57/ | Brief: spring-garden-article | Published | Jo | 2026-10-03 | No change planned |
Copy this blank structure and adapt it to your process:
| Site name and domain | Post title | Published URL | Edit URL, if available | Source reference | Status | Responsible editor | Last verified date | Next action |
|---|---|---|---|---|---|---|---|---|
| [site — domain] | [title] | [public URL] | [editor URL or blank] | [document, brief, or change note] | [verified state] | [person] | [date checked] | [specific next step or none] |
Use one row per destination-specific post. Keep status wording factual: “Published; correction pending” tells the next editor more than “in progress.” Add a public URL only after you have checked the destination. Update “last verified” after inspecting the live page, not simply after opening the editor. If you cannot confirm a value, label it “unknown—check” rather than filling the gap with a guess. Give the next action a verb, such as “compare shared paragraph” or “confirm access.”
The three-site example also shows why titles are not unique identifiers. Northline and Field Notes use the same sample title, but their public URLs and source references differ. Studio Ledger has a related subject, but a different title and brief. When you return to the register, use the domain and URL first, then compare the source and status before taking action.
Find and update the correct existing post
Use the register to identify the destination, then follow one correction all the way through. In this hypothetical example, Mira is reviewing the Northline entry. The approved source, “balcony-herbs-v3,” says the live article’s watering sentence is outdated. To make the example concrete, assume the current public text reads, “Water the herbs every day.” The approved replacement says, “Check the soil before watering; water when the top layer feels dry.” These sample sentences are illustrative content, not gardening advice or claims about a real article.
- Match the destination. Start with the Northline name and domain in the row. Open the listed public URL and make sure its address is on northline.example. A familiar headline alone is not enough, especially when another row has a similar title.
- Compare the current passage with the source. Locate “Water the herbs every day” on the public page and compare it with the correction in balcony-herbs-v3. If the page already has the approved replacement, do not apply it again; record that the correction is already present and check whether the register needs updating.
- Find the existing post entry. Use the available editing route associated with the Northline site to locate the post matching that public URL. Confirm that it is the existing article, not a new draft or a similarly titled item. If the edit URL is missing or no longer works, use the site’s normal route to locate the item and update the register when you have a reliable edit link.
- Change only the identified sentence. Replace “Water the herbs every day” with “Check the soil before watering; water when the top layer feels dry.” Leave the rest of the article alone unless the approved source calls for additional changes. If the live wording and source disagree in a way that makes the right replacement unclear, pause and ask the content owner which source governs.
- Review and save under the site’s normal process. Check that the editor contains the intended wording and that you have the Northline post open. Use the site’s applicable review or publishing process. If another person must approve the change, leave it pending rather than marking it published.
- Inspect the public URL again. Reopen https://northline.example/balcony-herbs/ and locate the sentence. In this hypothetical outcome, the page displays “Check the soil before watering; water when the top layer feels dry.” The old sentence is gone, the surrounding paragraph still reads sensibly, and the address remains the Northline URL.
- Write down the result. Update the row with the actual status, date, and any work left on related versions. The verified result is not “all copies updated”: Field Notes still needs a separate review.
The resulting hypothetical Northline row is:
| Site name and domain | Post title | Published URL | Edit URL, if available | Source reference | Status | Responsible editor | Last verified | Next action |
|---|---|---|---|---|---|---|---|---|
| Northline Journal — northline.example | A Guide to Balcony Herbs | https://northline.example/balcony-herbs/ | https://northline.example/editor/post-241/ | Docs: balcony-herbs-v3; correction note | Published; corrected and public page checked | Mira | 2026-10-26 | Compare Field Notes version; retain its local CTA |
The values and outcome are hypothetical. They show what a useful record looks like after the public check: the source is identifiable, the status describes what was observed, and the next action names the remaining destination. The correction is complete for Northline only. The separate Field Notes entry remains pending until someone checks that post.
If the source and public version disagree, do not silently decide that either one is authoritative. Record the mismatch and ask the content owner which version or source should govern. Once resolved, note the chosen source reference, then proceed. If access to a destination is blocked, leave it unverified and record the site or URL, the access issue, and who must resolve it. Do not substitute a similar post on a site you can reach.
For a related task after the article is ready to publish, see how to publish a WordPress post without losing the approval handoff. This guide is about finding and maintaining an existing post, rather than moving a new post through that handoff.
Keep versions on different sites from drifting unnoticed
Related posts may share some text and intentionally differ elsewhere. Give the related versions a shared-content label, identify which elements should be reviewed together, and record local details that should stay distinct. This makes the decision visible before someone copies a whole post from one site to another.
Continue the hypothetical example. Northline and Field Notes both have a general watering sentence that is intended to match. Their calls to action are different by design: Northline invites readers to join its newsletter; Field Notes points readers to its own local planting calendar. Mira’s correction changes the shared watering sentence, not either destination’s call to action.
| Part of the post | Northline Journal before | Field Notes before | Decision after review |
|---|---|---|---|
| Shared watering sentence | “Water the herbs every day.” | “Water the herbs every day.” | Replace on both with “Check the soil before watering; water when the top layer feels dry.” |
| Site-specific call to action | “Join the Northline newsletter for seasonal notes.” | “See the Field Notes local planting calendar.” | Keep each call to action on its own site; do not copy one over the other |
For this example, the register’s shared-content group could be “balcony-herbs-guide.” Add “watering sentence” under shared elements and “newsletter invitation” or “local planting calendar” under site-specific elements. When Mira completes Northline’s edit, the Field Notes row stays open until Dev or another assigned editor checks its public URL and decides whether the shared correction applies there.
The disposition is explicit: Northline is corrected and publicly checked; Field Notes is pending review. If Dev finds the old sentence on Field Notes, the same approved correction is made there, its public URL is reopened, and the result is recorded in that row. If Field Notes already contains different wording, Dev compares it with the approved source and asks the content owner if the intended change is unclear. Either way, the local call to action remains as recorded unless a separate instruction changes it.
If a tool is being used to synchronize content, check its documented behavior and configuration before treating the second row as complete. The Simple WordPress Crossposting documentation describes explicit post-syncing capabilities for that tool. Other access views and editing workflows should not be treated as synchronization unless their own documentation establishes that behavior. The register still needs a destination-by-destination outcome: it tells editors which versions were checked and which differences are intentional.
Run a short recurring cross-site post review
Choose a review rhythm that fits how often you publish and revise. A publisher with a small number of active posts might review the list when a correction arrives. Someone managing frequent updates may choose a regular review slot. The point is to make open work visible, not to follow a universal schedule.
Use the review to work through four kinds of loose ends:
- Unresolved updates: Find rows with a next action. Confirm that someone owns it, and list every destination affected by a shared correction.
- Missing source references: Add the document, brief, or change note if it is available. If the source cannot be found, mark it as unknown and decide whether that prevents safe editing.
- Status mismatches: Compare the record with the site. If a row says “published” but the public URL does not show the post, investigate before changing the record to a different status.
- Unverified or related versions: Reopen the public URL for changes that have not been checked. For shared-content groups, inspect each destination that the change is meant to affect and preserve recorded local differences.
A cross-site update is finished when the intended post on the intended domain displays the intended change, the register records the result and verification date, and every related version has either been checked or clearly assigned for follow-up. “Northline corrected; Field Notes pending review” is a valid current record. “Updated everywhere” is not useful unless each destination has been checked or a documented synchronization process has been verified.
Start with a small set of existing posts. Record each post’s domain, public URL, source, status, owner, and next action. Then complete one correction from source comparison through public-page review, leaving related versions with an explicit disposition. If a central view would help you locate content across sites, Tenwrite’s content index is one option for viewing and managing content across multiple sites; confirm that its current scope fits your process. It does not replace the record of which source and destination belong to an individual update.
The useful outcome is straightforward: you can find the post, identify the version you mean to change, and show what happened at each destination. Register a handful of existing posts and complete one verified update to put the process to work.