SnagitPro's guides are researched from product documentation and other identified sources. Reading those sources does not prove that a procedure was performed on a Windows PC or a Mac. Use the article's evidence label, stated scope, and sources to see what was checked.
This page describes the current required process, not a certification of every older article. The publishing workflow uses AI-assisted research, drafting, and editing, as explained in the editorial policy. AI output still needs verification and is not a test result.
What our evidence labels mean
- Documentation checked: the specified claims were compared with primary or authoritative sources. The article should name the date, product/platform scope, and any remaining limitation. This is not a hardware test.
- Community-reported: real, findable reports support the described observation. Link to those reports and identify the relevant setup where known. The label does not establish how common a problem is or guarantee a fix.
- Hands-on tested: the procedure was actually performed. Record the app and operating-system versions, relevant hardware or settings, test date, and observed results. Do not extend a result to devices or versions that were not tested.
A benchmark published by someone else must stay attributed to that source. A generic “verified” badge, byline, or review date cannot replace the evidence and scope of an individual check.
Research the reader's question
Start with the task and platform: choosing a capture tool, repairing a failed command, editing an image, or documenting a process. Compare the main search query with 5–12 relevant related questions and check whether an existing guide or hub already answers them.
The research record should preserve the actual search results inspected, their page types and intent, the date, and any visible related questions. If only six results are available, record six; do not claim a top-ten review. Do not invent People Also Ask questions or search-volume figures when the source does not expose them.
Verify claims with primary evidence
For Snagit, begin with TechSmith's Snagit tutorials, the TechSmith Support Center, release notes, and the relevant store or license terms. Use operating-system documentation and each comparison product's own sources where they control the answer.
Keep a claim record with the exact source, the supporting section, evidence date, and outcome: verified, qualified, or removed. Separate claims about versions, prices, plan limits, platform support, menu paths, file formats, causes, warnings, and recommendations. One working source link does not validate every sentence around it.
For a price, check the region, currency, plan, and purchase route. For a procedure, check the app version and platform. If official sources disagree, explain the difference or limit the conclusion. An unsupported claim cannot become “community-reported” unless real reports support it.
Save, check, correct, and check again
Work on one guide at a time. Save the draft, read the complete saved version, compare its claims with the evidence, and correct every justified issue before the next pass.
The current standard requires ten consecutive complete checks of the same saved revision without unresolved critical or high-impact issues. A material change to the text, links, structured data, or hub relationship resets that count. Ten requests to a URL or ten identical automated checks do not meet this requirement.
Each full check must cover the reader's intent and related questions, every factual claim, natural language, title and description, contextual links, visuals, and relevant structured data. Compare FAQ answers and other schema properties with the visible page, not just whether the JSON parses. The pass record must state its findings and evidence.
Check the draft preview before publication, then inspect the public page after publication. Verify its canonical URL, indexability and sitemap inclusion where appropriate, headings and jump links, link destinations, image loading, and mobile layout. A live link check alone is not a complete factual review.
For an already published guide, preserve a backup before correcting it and apply the same unchanged-revision checks before marking its audit complete. Repeated reading improves the review process; it does not establish hardware behavior that was never observed.
Images and walkthrough visuals
Generated and reconstructed interface graphics are illustrations, not official screenshots or records of a test. A caption cannot turn generated artwork into an authentic capture; an actual screenshot needs a known source. Controls and labels can differ by release and platform.
Visual checks cover useful content, readable labels, dimensions, efficient delivery, alt text, and captions. Keep credentials, license keys, private customer data, and identifying account details out of capture material. When an audit freezes existing images, alt text, or captions, those fields must remain unchanged.
When a guide needs an update
A changed menu, license rule, supported version, or documented error can require a correction. State what was reviewed and when. An Updated date records an edit; it does not prove that the entire guide was retested.
The corrections policy explains material correction notes and how to report a claim that no longer matches. Include the page URL, disputed step or statement, and relevant product/platform details. The About page explains the publication and its editorial byline.
Method correction, September 12, 2026: clarified that community evidence requires real reports, separated draft checks from post-publication checks, and made the saved-revision review requirements and limits explicit. Removed wording that implied universal past compliance.
Last reviewed: September 12, 2026.