How do Wikipedia’s conflict of interest policies affect what we can actually edit ourselves?

Wikipedia’s COI policies do not prohibit interested-party work on articles – they prescribe how to do it. WP:COI defines conflict of interest broadly to include subjects, their employees, their PR firms, and anyone with a material relationship to the topic. WP:PAID requires disclosure for any compensated editing. Together they shape a clear workflow: disclose the relationship publicly through the editor’s user account, work through Talk-page edit requests rather than direct edits, source each proposed change to reliable independent secondary outlets, and let community editors evaluate and implement. The compliant version of this work is durable and respected. The non-compliant version – undisclosed sockpuppet accounts, direct edits, promotional sourcing – is the version that produces sanctions, lasting article instability, and material damage to the client. Five Blocks operates exclusively in the compliant lane.

How do you request a review of a Wikipedia page that has been unfairly edited?

Wikipedia has a graduated escalation system for disputes, and using it correctly matters because skipping levels typically gets the case dismissed back to the level it should have started at. The first level is the article’s Talk page: identify the specific edits at issue, cite policy, propose alternatives, and try to build consensus with the involved editors. If the dispute concerns a specific policy (sourcing, NPOV, COI), the relevant noticeboard – Reliable Sources Noticeboard, NPOV Noticeboard, Conflict of Interest Noticeboard – is the right next level, and brings uninvolved expert editors into the discussion. The Dispute Resolution Noticeboard is for content disputes that have stalled after good-faith Talk-page work. ArbCom is for entrenched conduct disputes that the lower levels have failed to resolve. Each escalation gets logged, so handling the lower levels carefully strengthens the case if higher escalation becomes necessary.

Is it legal to edit your own Wikipedia article if you disclose who you are?

Legality is the wrong frame – Wikipedia is not a legal jurisdiction – but the policy answer is yes. Wikipedia’s WP:PAID and WP:COI policies explicitly permit interested-party editing under specific conditions: public disclosure of the relationship on the editor’s user page, in Talk page contributions, and in edit summaries; engagement through Talk-page edit requests rather than direct article edits; reliable secondary sources for proposed changes; and neutral encyclopedic tone in proposed content. This is the disclosed-COI model that Five Blocks operates under and that the major PR firms and law firms increasingly require their reputation partners to use. Editing without disclosure – sockpuppet accounts, anonymous edits, undisclosed compensation – is the version that breaks the rules and creates the lasting damage clients hire firms to avoid.

How do you handle a Wikipedia page written primarily by critics of the subject?

Critic-dominated articles emerge when a subject becomes the focus of sustained negative coverage and the article reflects that coverage without proportional context. The instinct to argue for removal of the critical content rarely succeeds and typically backfires – if the critics’ positions are documented in reliable secondary sources, NPOV does not permit their removal. The effective approach is additive: source the omitted context that exists but has not made it into the article. That can be the company’s substantive response to the criticism (documented in mainstream coverage), favorable third-party analysis that has been published but not cited, awards and recognition that balance the picture, or relevant context that recasts the framing. Proposed through Talk-page requests with explicit reference to NPOV’s proportional-weight requirement, well-sourced balancing content is generally implemented because policy supports it. The article becomes balanced rather than censored, which is the only durable outcome Wikipedia allows.

How do you handle a Wikipedia page that contains biased language?

Biased language on a Wikipedia article comes in two flavors: promotional copy inserted by previous PR-style edits, and critical or pejorative framing inserted by hostile editors. The remediation process is the same. Open a Talk page section, identify the specific biased phrasing, cite the NPOV policy (WP:NPOV) explicitly, and propose neutral encyclopedic wording supported by reliable secondary sources that establish the factual substance without the loaded framing. Community editors who watch the article will evaluate the proposal, and policy-compliant rewrites are typically implemented within days. The failure mode to avoid is editing the article directly to soften or harden language without sourced rewording – those edits get reverted, the dispute escalates, and the underlying bias remains because the community has lost trust in the editor proposing the change.

How do you manage a Wikipedia page for a person who has multiple notable roles?

Wikipedia biographies of people with multiple notable roles – a founder who became a board director who later became a public-affairs figure, an executive who is also a published author and philanthropist – have a standard structural pattern that handles the complexity cleanly. The main biography covers the person chronologically with sections for each major role or phase. Where a specific role has standalone notability (a notable book they wrote, a foundation they run, a company they founded), that role can have its own dedicated article cross-linked from the biography. Disambiguation is handled through Wikipedia’s disambiguation pages and through Wikidata identifiers that explicitly tie the person to their distinct roles. The Talk-page workflow for these biographies is the same as for any other – propose changes with sources – but the section structure benefits from up-front planning during the content gap analysis phase of an engagement.

What is a Wikipedia content gap analysis?

A content gap analysis is the foundational diagnostic we run at the start of most Wikipedia engagements. It compares the current state of the article against an ideal version for a company or executive at the client’s stage and scale: a strong lead paragraph, complete history section, accurate leadership and governance, current financials and operations, balanced coverage of any controversies, recognition and awards where notable, and a robust reference section. Each section gets assessed for accuracy, sourcing quality, recency, and policy compliance. The output is a prioritized list of gaps with proposed sourcing – which mainstream news pieces, regulatory filings, academic references, or trade publications can support each addition. The gap analysis then becomes the working plan for the engagement, executed through the standard Talk-page edit-request workflow.

How do you build Wikipedia pages for multiple entities within the same organization?

Multi-entity organizations – parent companies with subsidiaries, holding companies with portfolio entities, conglomerates with multiple notable brands – require careful Wikipedia architecture so each entity is correctly represented and the relationships are machine-readable. The parent-company article covers the corporate entity at the consolidated level: history, leadership, financials, structure. Subsidiaries and notable products get their own articles where standalone notability supports them, with clear cross-linking from the parent article and from each other where the relationships are direct. Wikidata is the structural layer underneath that ties them together: each entity has its own Wikidata item, with explicit parent-subsidiary, owner-owned, and predecessor-successor relationships. That entity infrastructure is what AI engines and the Google Knowledge Graph read to understand the corporate family, and it is what produces accurate disambiguation in AI responses about any one of the entities.

What is the process for getting a Wikipedia page undeleted?

There are two paths back to a deleted Wikipedia article. The first is Deletion Review (WP:DRV), which is appropriate when the original deletion misapplied policy – for example, a notability assessment that overlooked existing coverage or a deletion discussion that did not follow proper procedure. DRV is a formal process: the requesting editor presents the specific procedural or policy error, and the community reviews. The second path is recreation, which requires materially new notability evidence: substantial mainstream coverage published after the deletion that establishes the subject’s notability through independent reliable sources. Recreating an article without new evidence typically results in speedy deletion under WP:G4 (recreation of deleted material) and can lead to article protection against recreation. The careful path is to build the source environment first and then propose a new article through Articles for Creation review.

How do you manage a Wikipedia page for a company that operates across multiple countries?

Multinational companies present two distinct Wikipedia challenges. The first is sourcing on the English-language article: covering global operations accurately requires sources from the relevant regions, which can mean tracking down trade publications, language-specific mainstream press, and regulatory filings in markets that do not appear easily in an English Google search. The second is presence across the language Wikipedias themselves – de.wikipedia.org for German-speaking markets, fr.wikipedia.org for French, es.wikipedia.org for Spanish, ja.wikipedia.org for Japanese, and so on. Each language Wikipedia is its own community with its own notability conventions and editor base. Where notability supports articles in multiple languages, we work across them through disclosed-COI accounts on each. The Wikidata layer ties everything together: a single canonical entity ID with the language Wikipedia articles linked as sitelinks, which keeps the entity coherent for AI engines and the Knowledge Graph regardless of which language the user is querying in.