Guide: How to Get Paid to Write for CNET (Step by Step)

Write only what you can prove

For every claim, ask: “How do I know this is true?” Then add: a source link, a screenshot, a test result, or a direct quote. If you cannot prove it, rewrite it as a question or remove it.

• Use primary sources when possible (official docs, product pages, government sites).
• Use reputable secondary sources (major outlets, well-known research orgs).
• Keep notes: “Source for this line is X.” Editors love this.

Be honest about testing, limits, and updates

If you tested something, say how. If you did not test it, do not fake it. If your topic changes often (prices, deals, software steps), add an “Updated” line.

• Example: “We tested this on iPhone iOS 17 and Android 14.”
• Example: “Prices can change; check retailer page for latest.”

Never write like an advertisement

Big publications protect trust. If you sound like a brand promo, you lose. Your job is to help readers decide — sometimes that means saying: “Do not buy this” or “this is not worth it.”

• Use balanced pros/cons.
• Compare alternatives.
• Describe who should avoid the product.

Make your draft “easy to check”

Editors and fact-checkers move faster when your piece is organized. Use headings, short paragraphs, and “why this matters” lines.

• Add a quick summary near the top (3–5 bullets).
• Put numbers in tables when possible.
• Use clear labeling for screenshots and steps.

Write 2 simple how-to guides (tested)

Pick problems you can genuinely test. Example topics:

• “How to clear cache on Chrome (desktop + Android) — plus when NOT to do it.”
• “How to stop spam calls on Android/iPhone — settings + best free options.”
• “How to improve Wi-Fi at home: router placement, settings, and quick tests.”

Your rule: every step must be real. If you cannot test it, do not write it.

Write 2 explainers (definition + decision)

Explainers are great for beginners because you can do strong research without owning expensive devices. But you must link sources.

• “What is eSIM — and should you use it?”
• “What is Wi-Fi 7 — who needs it and who doesn’t?”
• “What is passkey login — why it matters and how to set it up?”

Format tip: define → why it matters → who it’s for → steps → common mistakes → FAQ.

Write 1 mini-buying guide (honest + practical)

Write something like: “Best budget earbuds under $X” — but do it responsibly:

• Explain your selection criteria (comfort, battery, calls, warranty).
• Include “best for…” categories.
• Be honest: “I did not test all of these; these are research-based picks.”
• Link to manufacturer specs and reputable reviews.

If you can test 1–2 items you own, add a mini “hands-on” section. That increases trust.

Create a “CNET-ready” portfolio page

Make one page that lists your best 6 clips (links). Add 1–2 lines under each clip explaining what skill it proves: tested steps, clear explanations, product comparisons, etc.

• Keep it simple: name, location, niche, 6 links, contact.
• Optional: add a Google Drive folder with screenshots and notes.
• Optional: add a “tools I use” section (phone models, apps, speed-test tools).

When you pitch, you send this one link. Make it clean.

Hands-on testing (best for how-to)

Do the steps yourself, then write while your memory is fresh. This is how you avoid fake or outdated instructions.

• Write down your device model + OS version.
• Take screenshots for tricky steps.
• Note “gotchas” (where you almost clicked the wrong thing).
• Note error messages exactly (spelling matters).

Make the reader feel: “This person actually did this.”

Source-based research (best for explainers)

If you cannot test something directly (example: new tech standard), you can still write a great explainer by using primary sources.

• Use official pages (manufacturer, standards org, government sites).
• Use reputable explainers (major tech outlets, respected research labs).
• Use quotes carefully (short, accurate, with links).
• When sources disagree, say so.

Editors trust writers who admit uncertainty instead of pretending.

Create one Google Doc before you write

Make a doc with these headings:

• Goal: what does the reader want to do?
• Audience: who is reading?
• Steps / Outline: headings you will use.
• Sources: links + 1 line note per link.
• Testing notes: device, OS, results, screenshots list.
• Risks: anything that can change quickly (prices, UI updates).

This doc becomes your “proof of quality” when working with editors.

Use a “double-check pass” (10 minutes)

Before you submit a draft, run a fast scan:

• Click every link. Replace broken ones.
• Confirm every number (prices, dates, specs).
• Remove “maybe” language unless needed.
• Turn long paragraphs into 2–3 short ones.

This tiny step is what makes your writing feel professional.

Never fake hands-on testing

If you didn’t test it, do not write “we tested.” Use clear language: “Based on specs and reputable reviews…” or “We have not tested this unit.”

• If you did test: explain your test conditions briefly.
• Use photos or screenshots when possible.
• Keep a test log (date, device, settings, notes).

Be clear about deals and pricing

Deals change fast. If you write deals content, you must update. Build habits:

• Always include the retailer link where the price lives.
• Add “Price as of [date/time]” if needed.
• Do not exaggerate savings. Show the math.

Many editors prefer writers who are careful over writers who are loud.

Disclose affiliate relationships correctly

Commerce writing often involves affiliate links. Publications have disclosure rules, and many also follow guidance like FTC endorsement rules. Learn the basics here: FTC Disclosures 101 and FTC Endorsement Guides FAQ.

• Disclosures should be clear and close to the recommendation.
• Do not hide it in tiny text.
• Never let affiliate money control your opinion.

Build a “comparison spine”

Great buying guides are not random lists. They have a spine: criteria → testing notes → best for categories → alternatives → who should skip.

• Criteria examples: battery life, call quality, comfort, warranty, support.
• Add “best for” labels: best budget, best premium, best for calls.
• Add “avoid if…” statements.

Confirm scope, deadline, and expectations

Reply quickly. Ask any missing details: word count range, required sources, testing needs, screenshot needs, headline style, and whether updates are expected.

• Confirm your deliverable format (Google Doc, CMS, etc.).
• Confirm if they want a short summary box at the top.
• Ask if you should include “FAQ” and “troubleshooting.”

Deliver a draft that is “editor-friendly”

Use clear headings and short paragraphs. Add source links near the claim. Add image/screenshot notes like: “Screenshot: Settings screen here.”

• Include your testing notes at the bottom (device + OS + date).
• List your sources in a short “Sources” section.
• Flag any uncertain areas for the editor (honesty builds trust).

Handle edits like a pro (fast + calm)

Editors may cut lines, rearrange sections, and ask for proof. This is normal. Your goal is to respond quickly and improve clarity.

• Do not argue emotionally.
• Reply with facts and options.
• If you disagree, offer an alternative line with reasoning.

Payment and paperwork (general expectations)

Payment details vary by organization and contract. In general, you may be asked for:

• W-9 (US) or local tax form, or contractor onboarding details.
• An invoice (some teams generate it; some want yours).
• Payment method setup (ACH, PayPal, etc.).
• Agreement terms (rights, exclusivity, edits, updates).

Keep a simple spreadsheet: assignment, rate, date delivered, invoice sent, paid date.