MC-Guide
Content Writing
Website 166: sitepoint.com
How Can You Earn Money Writing For sitepoint.com Website
This guide shows you, step by step, how a beginner can learn to pitch and sell stories to sitepoint.com
You will learn what sitepoint.com wants, how to test your idea, how to write a pitch, and how payment roughly works. You can use this like a small SOP.
Guide: How to Get Paid to Write for SitePoint (Step by Step)
A practical, beginner-friendly SOP that walks you from idea → outline → pitch → published article on SitePoint. Includes sample outlines, pitch text you can reuse, a publishing checklist, sample article structures, and a curated resource list so you can prepare a high-quality submission.
Use this as your personal template: copy the pitch examples, publish a sample earlier on Dev.to or your blog, and then adapt the outline when you fill SitePoint’s pitch form.
Section 1 · Understand the publication
What SitePoint actually wants from contributors
SitePoint is a long-established learning hub for web developers, designers, and digital makers. They publish tutorials, explainers, and practical guides across areas such as HTML, CSS, JavaScript, frontend frameworks, backend languages, UX, and the business side of web work. Your job as a contributor is to make a developer or designer’s next project easier to build — with clear steps, working code, and tested examples.
Read SitePoint’s official contributor information and any “write for us” instructions before you draft a pitch — it explains their current priorities, whether they are accepting pitches, and any editorial rules you must follow. (Links in the resources section at the bottom.)
What counts as a SitePoint article?
SitePoint publishes pieces in clear buckets:
- Step-by-step tutorials with runnable code (JS, Python, PHP, etc.).
- Best-practice guides on performance, accessibility, testing, or architecture.
- Tool-focused walkthroughs (Figma, Tailwind, Webflow, Notion automation).
- Business & freelance advice for web professionals (pricing, workflows, client onboarding).
If a working dev or designer can use your piece to solve a real project problem, you’re on the right track.
Who reads SitePoint?
The typical reader is a developer, designer, or maker who wants practical help — usually with some basic technical knowledge. They prefer short, clear paragraphs, code that copies cleanly, and real demos or links to GitHub/CodePen. High-level theory pieces can work, but only if they clearly connect to what a reader can do next.
Section 2 · Fit your idea
Is your idea shaped for SitePoint readers?
Don’t pitch a vague “intro to JavaScript” — instead, solve a specific problem (e.g., “Improve Core Web Vitals in React SPAs using dynamic imports”). Use these three checks to vet every idea.
Does it solve a real job?
Ask: After reading this, what concrete thing can the reader do better? If your piece doesn’t alter the reader’s next step, reshape it to focus on a workflow or decision.
Is the angle specific & different?
Search SitePoint to make sure your angle hasn’t already been covered in the same form. If it has, pick a fresh angle: compare frameworks, show migration steps, or present performance measurements from a real demo.
Can you back it up with evidence?
The strongest articles include a demo (GitHub, CodePen), screenshots, and a clear “before → after” result. If you only have theory, build a minimal demo first — that demo will form both your article body and your proof for the editor.
Section 3 · Prepare your samples & demo
Build a small technical writing ladder
SitePoint editors want to see that you can finish and polish a tutorial. Before pitching, publish 2–4 strong samples on platforms like your own blog, Dev.to, or Medium. Include working code and a small demo repository.
Samples that impress
- At least one tutorial with runnable code (CodePen, GitHub repo).
- Screenshots, a short GIF, or a live demo URL.
- Clear structure: problem → steps → result → extra notes.
Publishing samples helps you practice the exact tone and structure SitePoint expects.
How to build a demo fast
- Pick a small, solvable problem (e.g., lazy load images in Next.js).
- Create a minimal repo with instructions in README.md.
- Add screenshots and one example output or measurement (before/after).
- Link the demo from your article and from your pitch.
| Stage | Where | Main goal |
|---|---|---|
| Practice | Your blog / Dev.to | Finish strong tutorials with code and demo |
| Proof | Smaller tech blogs | Get used to edits and feedback |
| Pitch | SitePoint | Submit a polished idea and a sample link |
Section 4 · Practical pitch workflow
How to fill SitePoint’s pitch form — exact practical plan
Use this as your step-by-step SOP for each pitch. Keep one doc where you store outlines and sample links — reuse and adapt it for future pitches.
Read the “Write for SitePoint” page carefully
SitePoint’s official contributor page contains the up-to-date guidance you must follow before pitching: topics they want, formatting hints, and whether they currently accept pitches. Start here and keep it open while preparing your outline.
Create one focused idea and one clear reader
Write one sentence answering: “Who am I helping?” Example: “Frontend devs who need to improve accessibility in a React dashboard.”
Prepare an outline + demo link
Your pitch should include 4–8 section headings and a short demo link (GitHub/CodePen). Editors rarely accept “vague” outlines.
One full sample article
Before pitching, publish one full tutorial elsewhere to prove you can finish a piece. That sample becomes your writing sample link.
Submit using SitePoint’s pitch form
Use the form linked on Write for SitePoint. Fill fields: short bio, topic ideas (1–3), a bulleted outline for at least one idea, and links to your best work.
Follow-up politely or reuse the idea
If you don’t hear back after a few weeks, a short polite follow-up is fine. If you still don’t get a yes, adapt the idea for other outlets (Dev.to, freeCodeCamp, personal blog).
Section 5 · Writing the article
Structure, code formatting and editorial expectations
SitePoint favors clear, practical, and tested tutorials. Below is a compact template you can use for most technical tutorials.
Universal Article Template (copyable)
- Title: Short, benefit-oriented (e.g., “Lazy-load Images in Next.js for Faster LCP”).
- Intro (150–250 words): State problem, why it matters, and the result the reader will get.
- Prerequisites: what the reader needs (versions, packages).
- Step-by-step: 4–8 sections with headings, code blocks, and short explanations.
- Demo/Repo link: GitHub or CodePen with a runnable example.
- Testing & verification: how you tested, performance numbers or screenshots.
- Wrap-up & next steps: suggestions for readers to extend the work.
Code formatting tips
- Use fenced code blocks (triple backticks) with the language (e.g.,
```js). - Keep snippets short and link to the full file in the repo.
- Include commands to reproduce the demo (install, run).
- Label screenshots and show before/after states when relevant.
Accessibility & testing
State how you tested accessibility (screen reader steps, keyboard navigation) and any performance checks (Lighthouse/Core Web Vitals).
Small verification details build trust — editors notice this and it speeds the review process.
Small example: Lazy load images (minimal)
// Example: basic native lazy-loading in HTML
<img src="hero.jpg" alt="Beautiful skyline" loading="lazy" width="1200" height="800">
// React example using IntersectionObserver (simplified)
function useLazyLoad(ref) {
useEffect(() => {
const el = ref.current;
if (!el) return;
const io = new IntersectionObserver(entries => {
entries.forEach(e => {
if (e.isIntersecting) {
const img = e.target;
img.src = img.dataset.src;
io.unobserve(img);
}
});
});
io.observe(el);
return () => io.disconnect();
}, [ref]);
}
When you include code in your article, make sure each example runs (or include a tested minimal reproduction in the repo).
Section 6 · Money, rights & negotiation
How payment usually works (and what to expect)
Payment rates can change. Public guidance and writer reports suggest SitePoint commonly pays a flat fee per accepted article — often in the low hundreds of USD for typical tutorials, with higher fees for long-form or traffic-performing pieces. Always confirm the exact amount in the editor’s offer note. (See resources for more details.)
What to expect
- Flat fee per article agreed in the acceptance email.
- Editors will usually help with copy edits and technical clarifications.
- Promotion via SitePoint’s homepage, newsletter, or social media may be part of the package.
Business thinking
Divide the offered fee by your estimated hours (research, coding, writing, edits) to get an effective hourly rate. Treat SitePoint pieces as both cash and portfolio-building work — high-quality pieces can be repurposed into talks, courses, or consulting leads.
| Piece | Rough pay picture* | Suggested strategy |
|---|---|---|
| Short tutorial | Lower–middle range | Good entry piece; be crisp and demo-focused |
| Deep multi-section tutorial | Middle–higher | Make a flagship piece with a serious demo and repo |
| Series | Fee per piece | Negotiate for a series or follow-up pieces |
Section 7 · Promotion & SEO
Get the most value from your published article
Once published, your article is a long-term asset. Promote it, link to it from your portfolio, and reuse the core project as a talk, workshop, or course module. A simple promotional plan can multiply the long-term value of a single SitePoint piece.
Simple promotional checklist
- Share the piece on Twitter / X, LinkedIn, and developer communities.
- Post a short thread or carousel that shows the “before → after”.
- Link the article in your portfolio and in job/freelance proposals.
- Create a short video (1–3 min) showing the demo and link to SitePoint in the description.
SEO quick wins
- Use a clear keyword phrase in the title and first paragraph.
- Write descriptive alt text for screenshots and images.
- Link to official docs and related SitePoint articles when relevant.
Section 8 · Ethics, AI & verification
How to use AI tools responsibly and keep trust
AI can be a useful assistant, but editors expect human ownership of the final piece. Do not submit AI drafts as-is. Use tools to brainstorm or to tighten prose — then verify every code example yourself.
What not to do
- Don’t submit untested code or AI-generated text without verification.
- Don’t copy other sites’ text or code without permission and attribution.
- Don’t invent results or fake production numbers.
Safe AI usage
- Use AI to brainstorm titles and section headings, then rewrite.
- Use AI as a reviewer for grammar and clarity, but maintain manual testing of code.
- Document any AI assistance if the editor asks (some publications request transparency).
Section 9 · Ready-to-send pitch & email templates
Copy-paste pitch templates (adapt as needed)
Short pitch (1 idea) — for beginners
Hi SitePoint team,
I'm [Your Name], a frontend developer who builds React apps and teaches via short tutorials. I’d like to pitch an article:
Title: "Improve Core Web Vitals in React SPAs with Adaptive Image Loading"
Audience: frontend developers using React/Next.js who want quick performance wins.
Outline:
1) Why LCP matters in SPAs
2) Strategy overview: adaptive image loading
3) Example: Next.js 13 app setup (repo link)
4) Implementing intersection-based loading + responsive srcset
5) Measuring improvements (Lighthouse)
6) Wrap-up & deployment notes
Sample work: [link to 1–2 tutorial samples]
Demo: [GitHub repo link]
Short bio: I write tutorials at [your blog]; previously built [small client/project]. Happy to expand the outline if you'd like.
Thanks,
[Your Name] — [Email] — [Twitter/Website]
Multi-idea pitch (3 short ideas)
Hi SitePoint editors,
I'm [Your Name]. I have 3 short ideas for tutorials:
1) "A Beginner's Guide to Tailwind + React: Building a Responsive Dashboard" — includes repo + accessibility notes.
2) "Automate Client Onboarding with Airtable + Zapier" — step-by-step workflow for freelancers.
3) "Simple Image Optimization for Static Sites" — techniques for Webpack, Next.js, and manual builds.
My preferred idea to pitch now is #1 — outline attached. Sample writing: [link]. Demo: [link]. Bio: [one-sentence].
Thanks for considering — happy to discuss edits or angle tweaks.
— [Name]
Section 10 · Final checklist & curated resources
Final pre-pitch checklist
- Write for SitePoint — official contributor page
- SitePoint Community Forums
- SitePoint home — sections (JS, CSS, Python, etc.)
- Get Paid to Write About HTML, CSS, and Sass — historical SitePoint guidance
- Dev.to — publish lightweight tutorials
- CodePen — quick live demos
- GitHub — host repo demos
- Public pay guide / memory of contributor rates