SOP 6: Shopify App Review Design, Publishing, and Quality Assurance

SOP Information

1. Purpose

The purpose of this SOP is to define how Blinto prepares approved Shopify app review content for publication, creates and processes supporting visuals, implements the article in the content management system, completes final quality assurance, publishes the content, and verifies that the live page works correctly.

This process ensures that every Shopify app review:

• Maintains the accuracy and structure of the approved content.
• Uses clear, useful, and consistent visual elements.
• Provides a strong reading experience on desktop and mobile.
• Includes properly formatted tables, screenshots, links, metadata, and calls to action.
• Meets Blinto’s SEO, accessibility, technical, and editorial standards.
• Is crawlable and indexable.
• Uses appropriate canonical and structured-data settings.
• Displays correct author, reviewer, testing, and update information.
• Contains no broken links, missing images, formatting problems, or publishing errors.
• Is ready for promotion, performance tracking, and future maintenance.

No Shopify app review should be published without completing this SOP.

2. SOP Objective

This SOP helps Blinto:

• Maintain a consistent design system across all Shopify app review content.
• Turn the approved draft into a polished live article.
• Make complex app information easier to understand.
• Protect the accuracy of the approved article during CMS implementation.
• Improve readability and user experience.
• Implement on-page SEO requirements correctly.
• Prevent broken links, incorrect metadata, and indexing problems.
• Apply appropriate structured data.
• Confirm that disclosures and trust signals are visible.
• Test the article across desktop and mobile devices.
• Create a clear publication and post-publication verification process.
• Prepare the article for promotion, measurement, and maintenance.

3. Scope

This SOP covers:

• Approved-content handoff
• Design planning
• Featured-image creation
• Screenshot preparation
• Image editing and privacy checks
• Comparison-table formatting
• Supporting graphic creation
• Image compression and file naming
• Alt text and captions
• CMS page creation
• Content formatting
• Metadata implementation
• URL and slug setup
• Internal linking
• External source linking
• CTA implementation
• Author and reviewer information
• Testing and disclosure implementation
• Structured-data implementation
• Breadcrumb implementation
• Canonical setup
• Indexability checks
• Desktop and mobile quality assurance
• Accessibility checks
• Final approval
• Publishing
• Post-publication verification
• Documentation and handoff

This SOP does not cover:

• Topic selection
• App research and hands-on testing
• Content-brief creation
• Content writing
• Editorial, SEO, or technical content review
• Founder outreach
• Social promotion
• Link building
• Performance tracking
• Content-refresh execution

These activities are handled through other SOPs.

4. Entry Requirements

SOP 6 begins only when:

• SOP 5 has been completed.
• The article has received final editorial approval.
• The article has received final SEO approval.
• Required technical claims have been approved.
• The ClickUp status is Content Approved for Design and Publishing.
• The final clean draft is attached.
• The final title is approved.
• The recommended URL is approved.
• The title tag and meta description are approved.
• Required screenshots are identified.
• Required tables and graphics are identified.
• Internal-link targets are listed.
• CTA copy and placement are approved.
• Testing and commercial disclosures are confirmed.
• Author and reviewer information is available.
• Pricing verification date is recorded.
• The content-refresh date is recommended.
• The designer and publisher are assigned.

The publisher must not use an earlier draft or a document containing unresolved review comments.

5. Expected Output

At the end of this SOP, the team must have:

1. A final featured image.
2. Approved screenshots and supporting visuals.
3. Properly designed comparison and pricing tables.
4. Compressed and correctly named image files.
5. Complete captions and alt text.
6. A fully formatted CMS article.
7. An approved URL and page slug.
8. An implemented SEO title and meta description.
9. Correct internal and external links.
10. An implemented CTA.
11. Visible testing and commercial disclosures.
12. Complete author and reviewer information.
13. Appropriate structured data.
14. Correct canonical and indexability settings.
15. A completed desktop QA check.
16. A completed mobile QA check.
17. A completed accessibility check.
18. Final publishing approval.
19. A live article.
20. A completed post-publication verification.
21. A documented live URL.
22. A ClickUp status of Published and QA Verified.

6. Roles and Responsibilities

During the validation phase, one person may perform several responsibilities. However, the final live-page check should preferably be performed by someone other than the person who uploaded the article.

7. Required Tools and Resources

The team may use:

• Blinto’s content management system
• Approved page or blog template
• ClickUp
• Approved content document
• Screenshot and evidence folder
• Design software
• Image-compression tools
• Browser developer tools
• Desktop and mobile browsers
• Responsive design testing tools
• Google Search Console
• Google Analytics
• SEO plugin or CMS SEO controls
• Structured-data testing tools
• Link-checking tools
• Page-performance testing tools
• Accessibility testing tools
• Blinto website sitemap
• Blinto brand guidelines
• Blinto author and reviewer profiles

The publisher must have the necessary CMS permissions before beginning.

8. Required Templates and Checklists

The following resources should be available:

• Shopify App Review Featured Image Template
• Screenshot Preparation Checklist
• Comparison Table Template
• Pricing Table Template
• Pros and Cons Design Template
• Image Naming and Alt-Text Sheet
• CMS Publishing Checklist
• On-Page SEO Checklist
• Structured-Data Checklist
• Desktop QA Checklist
• Mobile QA Checklist
• Accessibility Checklist
• Pre-Publication Approval Checklist
• Post-Publication Verification Checklist
• Content Publication Record

9. Complete Design, Publishing, and QA Workflow

Step 1: Review the Approved Handoff

The designer and publisher must review the approved handoff from SOP 5.

Review:

• Final approved title
• Content type
• Primary keyword
• Search intent
• Target audience
• Main verdict
• Testing level
• Approved article
• Recommended URL
• Title tag
• Meta description
• Required screenshots
• Required tables
• Required graphics
• Visual-placement instructions
• Image-caption instructions
• Alt-text direction
• Internal-link targets
• External-source requirements
• CTA copy and placement
• Testing disclosure
• Commercial disclosure
• Author information
• Reviewer information
• Pricing verification date
• Recommended refresh date
• Schema recommendations

Handoff Check

Confirm that:

• The final draft is clearly labeled.
• No unresolved comments remain.
• All required assets are available.
• Visual requirements are understandable.
• Approved internal-link destinations exist or are marked as planned.
• The required CTA destination exists.
• The publisher has access to the correct CMS section.
• The article has not already been published under another URL.

Output

A confirmed production checklist.

Step 2: Create the Design and Asset Plan

Before creating visuals, prepare a simple asset plan.

Required Asset Plan Fields

• Asset name
• Asset type
• Article section
• Purpose
• Source material
• Required dimensions
• Desktop requirement
• Mobile requirement
• Publishable status
• Privacy-edit requirement
• Caption requirement
• Alt-text requirement
• Assigned owner
• Due date

Common Asset Types

• Featured image
• App dashboard screenshot
• Installation screenshot
• Onboarding screenshot
• Storefront screenshot
• Mobile screenshot
• Comparison table
• Pricing table
• Pros and cons graphic
• App scorecard
• Best-app-by-use-case graphic
• Setup process diagram
• Merchant decision flowchart
• Integration diagram
• CTA graphic

Only create visuals that improve understanding, trust, comparison, or decision-making.

10. Featured Image Creation

Step 3: Create the Featured Image

The featured image should make the content topic immediately understandable.

Featured Image Requirements

The image should:

• Follow Blinto’s visual identity.
• Clearly reflect the app, category, or comparison.
• Remain readable at thumbnail size.
• Avoid overcrowding.
• Avoid unverified ratings or claims.
• Avoid copyrighted promotional material that Blinto cannot use.
• Use approved app logos only where permitted.
• Work across blog cards, social previews, and the article page.
• Be consistent with other content in the project.

Recommended Featured Image Approaches

Single App Review

• App name
• Review label
• App category
• Simple Shopify-related visual
• App dashboard or interface-inspired element where permitted

Comparison Article

• App A versus App B
• Clear side-by-side visual
• Main comparison context
• No unsupported “winner” label before the article verdict

Category Review

• Category title
• Multiple app or workflow elements
• Merchant problem or use-case theme
• Clear “best apps” context

Featured Image Text

Keep image text short.

Examples:

• Judge.me Review
• Judge.me vs Loox
• Best Shopify Review Apps
• Top Shopify Dropshipping Apps

Do not place the full SEO title on the image.

Step 4: Review Logo and Brand Usage

Before using third-party logos:

• Confirm that the logo is publicly available for standard identification use.
• Do not alter the logo in a misleading way.
• Do not imply endorsement or partnership.
• Do not use badges such as “official partner” unless Blinto has that status.
• Do not place one app’s logo more prominently because of a commercial relationship.
• Follow any documented brand-usage requirements.

Where logo use is unclear, use neutral text or interface-based visual elements.

11. Screenshot Preparation

Step 5: Select Screenshots

Use screenshots that support important findings.

Possible Screenshot Types

• App Store listing
• Installation screen
• Permission screen
• Onboarding checklist
• Main dashboard
• Feature configuration
• Pricing interface
• Storefront output
• Mobile output
• Integration settings
• Reporting dashboard
• Support interface
• Error or limitation
• Uninstall process

Screenshot Selection Rules

Choose screenshots that:

• Demonstrate an important feature.
• Support a statement in the article.
• Help the reader understand setup or usability.
• Show an original Blinto test where available.
• Reflect the current app interface.
• Can be understood with a short caption.

Do not include screenshots only to make the article appear longer.

Step 6: Protect Private and Sensitive Information

Before publishing a screenshot, remove or hide:

• Email addresses
• Passwords
• API keys
• Access tokens
• Store URLs where private
• Customer names
• Customer addresses
• Order details
• Payment information
• Private support messages
• Internal account identifiers
• Client information
• Confidential test data

Use test data wherever possible.

Privacy Review

Every screenshot must be marked:

• Approved for publication
• Requires editing
• Internal use only
• Rejected

Internal evidence should not automatically be treated as publishable.

Step 7: Prepare Screenshot Presentation

Screenshots should be:

• Cropped to the relevant area.
• Clear and readable.
• Free from unnecessary browser clutter.
• Consistent in visual treatment.
• Large enough for important interface text.
• Usable on mobile screens.
• Supported by a caption where needed.

Do not crop away information necessary to understand the screenshot.

Annotation Rules

Annotations may be used to:

• Highlight a setting
• Show a workflow step
• Identify a feature
• Explain an interface element

Annotations must not:

• Change the meaning of the interface.
• Hide an app limitation.
• Create a false result.
• Suggest functionality that was not present.

12. Supporting Visual and Table Design

Step 8: Design Comparison Tables

Comparison tables should help readers understand important differences quickly.

Category Review Table Fields

Possible columns:

• App
• Best for
• Starting price
• Free plan
• Main strength
• Main limitation
• Testing level
• Overall score

Comparison Article Table Fields

Possible rows:

• Core use case
• Starting price
• Free plan
• Installation
• Ease of use
• Customization
• Integrations
• Support
• Scalability
• Best-fit merchant
• Winner by criterion

Table Rules

• Use approved and current information.
• Keep table text concise.
• Maintain consistent criteria.
• Do not include information that contradicts the body.
• Avoid excessive columns.
• Ensure horizontal scrolling works properly on mobile where necessary.
• Do not rely only on color to communicate the winner.
• Include explanatory notes for variable pricing or partial testing.

Step 9: Design Pricing Tables

Pricing tables should clearly show:

• Plan name
• Price
• Billing period
• Main included features
• Important limits
• Best-fit merchant
• Verification date

Pricing Table Rules

• Use official verified pricing.
• Make variable charges clear.
• Avoid hiding usage limits.
• Do not present yearly and monthly pricing as directly equal without explanation.
• Identify custom pricing.
• Include “pricing verified on [date]” near the table or pricing section.

Step 10: Design Pros and Cons Elements

Pros and cons should be visually balanced.

Requirements

• Use the approved content.
• Keep each point specific.
• Give strengths and limitations similar visual importance.
• Do not hide cons below an expandable element unless the full section remains accessible.
• Avoid promotional icons or labels that make the article feel sponsored.

Step 11: Create Decision-Support Graphics

Where useful, create:

• Best app by use case
• Merchant-fit matrix
• App selection flowchart
• Setup difficulty scale
• Pricing growth illustration
• Feature-availability matrix
• App-stack integration diagram

Decision Graphic Rules

• Use approved criteria.
• Keep the recommendation contextual.
• Include limitations.
• Avoid declaring an unsupported universal winner.
• Ensure the article text explains the graphic.

13. Image Optimization

Step 12: Name Image Files

Use descriptive filenames.

File-Naming Format

[primary-subject]-[feature-or-context].[filetype]

Examples:

• judgeme-review-dashboard.webp
• judgeme-vs-loox-comparison.webp
• best-shopify-review-apps.webp
• loox-onboarding-screen.webp

File-Naming Rules

• Use lowercase letters.
• Use hyphens.
• Avoid unnecessary numbers.
• Avoid spaces.
• Avoid generic names such as image1.png.
• Avoid keyword stuffing.
• Use the correct app name.

Step 13: Compress and Format Images

Before upload:

• Resize images to appropriate display dimensions.
• Compress files without making interface text unreadable.
• Use a suitable modern image format where supported.
• Keep transparent images only when transparency is necessary.
• Avoid uploading unnecessarily large source files.
• Test image quality on both desktop and mobile.

Image Quality Rule

Compression should not make screenshots difficult to read.

Interface screenshots may require higher clarity than decorative graphics.

Step 14: Add Alt Text

Alt text should describe the image’s purpose and visible content.

Good Alt Text

• Judge.me onboarding checklist showing product review setup steps
• Comparison of Judge.me and Loox Shopify app pricing plans
• Shopify development store displaying a Loox photo review widget
• Best Shopify review apps comparison table

Alt-Text Rules

• Describe the image accurately.
• Mention the app or feature where relevant.
• Keep it concise.
• Do not repeat surrounding text unnecessarily.
• Do not use “image of” unless required for clarity.
• Do not add keywords unrelated to the image.
• Use empty alt text for purely decorative images where appropriate.

Step 15: Add Captions

Use captions when they:

• Explain what the screenshot shows.
• Clarify the testing environment.
• Identify a limitation.
• Provide the screenshot date.
• Distinguish a tested feature from an official product image.

Example

Blinto tested Judge.me’s initial review-widget setup using a Shopify development store.

Captions should not make unsupported claims.

14. CMS Article Creation

Step 16: Create the CMS Draft

Create the article as a draft in the correct CMS location.

Confirm:

• Correct content type
• Correct category
• Correct author
• Correct page template
• Correct parent or archive relationship
• Correct draft visibility
• Correct website environment

Do not publish directly while uploading the article.

CMS Draft Name

Use the final approved article title.

Step 17: Set the URL Slug

The slug should:

• Match the approved recommendation.
• Be concise.
• Include the main topic.
• Use lowercase letters and hyphens.
• Avoid unnecessary dates unless the strategy requires them.
• Avoid stop words where they add no value.
• Avoid changing an existing indexed URL without a redirect plan.

Examples

• /shopify-apps/judgeme-review/
• /shopify-apps/judgeme-vs-loox/
• /shopify-apps/best-review-apps/
• /shopify-apps/best-dropshipping-apps/

Duplicate URL Check

Before confirming the slug:

• Search the CMS.
• Check the sitemap.
• Search the website.
• Confirm the URL is not already used.
• Confirm no unpublished draft uses the same slug.

Step 18: Upload the Approved Content

The publisher must copy only the final approved document.

Content Integrity Rules

Do not:

• Use an earlier version.
• Rewrite approved statements without review.
• Add new app claims.
• Change the verdict.
• Remove limitations.
• Add promotional copy.
• Change verified pricing.
• Remove disclosures.
• Replace approved internal links with unrelated pages.

If the CMS requires a wording change, the Content Lead must approve it.

Step 19: Apply Heading Structure

Confirm:

• One H1 is used.
• Major sections use H2.
• Supporting sections use H3.
• H4 is used only where necessary.
• Headings follow the approved hierarchy.
• No heading level is skipped without reason.
• Headings are not used for decorative styling.

The visible page title and CMS H1 should not conflict.

Step 20: Format Paragraphs and Lists

Use:

• Short paragraphs
• Bulleted lists where they improve scanning
• Numbered steps for workflows
• Tables for comparisons
• Callout boxes for verdicts or disclosures
• Bold text for key labels
• Proper spacing between sections

Avoid:

• Large blocks of text
• Excessive bolding
• Multiple nested lists
• Inconsistent spacing
• Decorative formatting that reduces readability
• Repeating the same information in a table and paragraph without need

Step 21: Format the Quick Verdict

The quick verdict should be visually easy to find.

Possible formats:

• Highlighted box
• Summary card
• Key recommendation section
• Short verdict panel

Quick Verdict Box May Include

• Overall recommendation
• Best for
• Main strength
• Main limitation
• Testing level
• Overall score where approved

The box must match the approved article content.

Step 22: Format Review Methodology and Disclosures

Place testing information near the beginning of the article.

Possible Fields

• Tested by Blinto
• Testing date
• Test store type
• Testing level
• Paid features not tested
• Pricing verified date
• Reviewed by Shopify expert
• Commercial disclosure

The methodology should be visible without requiring the reader to search for it.

15. Metadata Implementation

Step 23: Add the SEO Title

Use the approved title tag.

Verify:

• It matches the topic.
• The primary keyword is included naturally.
• It does not make unsupported claims.
• It is not duplicated by another page.
• It remains readable in search results.
• It is different from the H1 only when there is a clear reason.

Do not automatically rewrite the approved SEO title using a plugin suggestion.

Step 24: Add the Meta Description

Use the approved meta description.

Confirm:

• It accurately describes the article.
• It matches search intent.
• It explains the decision or value.
• It avoids unsupported claims.
• It does not promise information missing from the page.
• It does not contain unnecessary quotation marks or symbols.

Step 25: Add Social Metadata

Where supported, confirm:

• Open Graph title
• Open Graph description
• Social-share image
• X or other social-preview fields where applicable
• Correct canonical social URL

The social preview should use the correct featured image and article title.

16. Internal and External Linking

Step 26: Implement Internal Links

Use the approved internal-linking plan.

Possible Destinations

• Shopify app category article
• Single app review
• App comparison article
• Supporting Shopify guide
• Blinto Shopify service page
• Relevant case study
• Related educational resource

Internal-Link Rules

• Use contextual anchor text.
• Link only to live, relevant pages.
• Avoid excessive links.
• Avoid repeating the same destination unnecessarily.
• Confirm that the link opens correctly.
• Use the final approved URL.
• Do not invent URLs for unpublished content.

Planned Link Rule

When a supporting page is not yet live:

• Record the planned link in ClickUp.
• Do not publish a broken placeholder.
• Add the link after the destination is published.
• Include it in the content-maintenance task.

Step 27: Implement External Links

External links may support:

• Official app information
• Official pricing
• Shopify documentation
• App documentation
• Relevant standards
• Important factual sources

External-Link Rules

• Prefer original and official sources.
• Link only when the source helps the reader verify or understand a claim.
• Avoid unnecessary competitor links.
• Do not link to low-quality affiliate summaries as evidence.
• Confirm that all links work.
• Open external links according to Blinto’s website policy.
• Apply sponsored or affiliate attributes where required.
• Do not use a commercial relationship to influence source selection.

Step 28: Check Anchor Text

Anchor text should:

• Describe the destination.
• Fit naturally within the sentence.
• Avoid generic phrases.
• Avoid excessive exact-match repetition.
• Avoid misleading the reader.

Good Example

Compare the best Shopify product review apps.

Weak Example

Click here.

17. CTA Implementation

Step 29: Add the Approved CTA

Implement the approved CTA in the correct section.

Possible CTA Goals

• Get Shopify app selection support
• Request Shopify app integration help
• Discuss custom Shopify app development
• Improve an existing Shopify app
• Get Shopify app maintenance support
• Review a Shopify app stack
• Improve Shopify store performance

CTA Components

• Short heading
• Supporting explanation
• Primary button
• Optional secondary link
• Correct service-page destination
• Tracking setup where required

CTA Rules

• Keep the CTA relevant to the article.
• Preserve editorial independence.
• Avoid guaranteed-results language.
• Do not add multiple unnecessary CTA banners.
• Confirm the button works.
• Confirm the CTA is readable on mobile.
• Use approved button text.

Step 30: Test CTA Tracking

Where tracking is implemented, confirm:

• Button click event
• CTA name
• Article identifier
• Destination
• Analytics event
• Conversion path
• Form tracking where relevant

The tracking label should clearly identify the article and CTA.

18. Author, Reviewer, and Trust Information

Step 31: Add Author Information

The article should include:

• Author name
• Author image where required
• Short author biography
• Relevant Shopify or ecommerce expertise
• Link to author profile

Do not assign the article to a person who did not write or meaningfully contribute to it without internal approval.

Step 32: Add Reviewer Information

Where relevant, add:

• Reviewed by
• Reviewer role
• Relevant Shopify expertise
• Review date
• Reviewer-profile link

Technical reviews should identify an appropriate reviewer when the article contains significant technical claims.

Step 33: Add Date Information

The article should support:

• Original publication date
• Last updated date
• Testing date
• Pricing verification date

Date Rules

• Do not update the visible date without making a meaningful content update.
• Ensure the CMS date matches the planned publication date.
• Record the next recommended review date internally.
• Refresh pricing and screenshots before changing the update date.

Step 34: Add Editorial Disclosures

Where applicable, display:

• Testing level
• Features not tested
• Research-only limitations
• Affiliate relationship
• Sponsorship
• Free app access
• Existing client relationship
• Partnership relationship

Disclosure Rules

• Use clear language.
• Make the disclosure visible.
• Do not hide it only in the footer.
• Do not imply independence when the relationship affected the process.
• Preserve Blinto’s control over the verdict.

19. Structured Data and Technical SEO

Step 35: Select Appropriate Structured Data

The SEO Strategist should select markup that accurately reflects visible page content and current search-engine guidance.

Possible markup may include:

• Article or BlogPosting
• BreadcrumbList
• Person
• Organization
• FAQ markup only when appropriate and supported
• Other applicable types approved by the SEO Lead

Structured-Data Rules

• Mark up only content visible on the page.
• Do not add false ratings.
• Do not create unsupported review or aggregate-rating markup.
• Do not mark Blinto’s own editorial score as third-party user reviews.
• Do not add FAQ markup to content that does not contain visible FAQs.
• Use consistent author, publisher, date, image, and canonical information.
• Validate the final markup before publication.
• Follow current search-engine and Schema.org guidance.

Structured data may help search engines understand a page, but it must not be treated as a guarantee of enhanced search appearance.

Step 36: Implement Breadcrumbs

Confirm:

• Breadcrumbs reflect the approved site structure.
• Breadcrumb links work.
• The final page is placed in the correct category.
• Breadcrumb text is concise.
• Breadcrumb structured data matches the visible navigation.

Example:

Home → Shopify Apps → App Reviews → Judge.me Review

The exact structure should follow Blinto’s approved architecture.

Step 37: Set the Canonical URL

Confirm that:

• The canonical points to the final live URL.
• The canonical does not point to a draft or staging page.
• HTTP and HTTPS versions are consistent.
• Trailing-slash rules match the website.
• The canonical is self-referencing unless another approved strategy applies.
• Duplicate versions do not create conflicting canonicals.

Do not publish the page with a canonical pointing to another review unless intentionally approved.

Step 38: Check Robots and Indexability

Before publishing, confirm:

• The page is not set to noindex.
• The page is not blocked by robots controls.
• The category or parent structure allows crawling.
• Images required for search visibility are accessible.
• The page is not password-protected.
• The draft environment is not being indexed accidentally.
• The final page can be included in the sitemap.

Step 39: Review URL Redirect Requirements

If an existing URL is being changed:

• Create a permanent redirect from the old URL.
• Update internal links.
• Update the canonical.
• Update the sitemap.
• Check redirect chains.
• Record the change in ClickUp.

Do not change indexed URLs only to make the slug slightly shorter.

20. Pre-Publication Content QA

Step 40: Compare the CMS Page With the Approved Draft

The Content Lead should compare:

• Title
• Introduction
• Quick verdict
• Headings
• Tables
• Pricing
• Pros and cons
• Final verdict
• CTA
• Disclosures
• Author information
• Internal links
• External links

Confirm:

• No approved content is missing.
• No unapproved claims were added.
• Formatting did not change meaning.
• Special characters display correctly.
• App names are spelled correctly.
• Pricing and dates remain accurate.

Step 41: Proofread the CMS Version

Check for:

• Grammar
• Spelling
• Punctuation
• Capitalization
• Extra spaces
• Broken symbols
• Incorrect heading case
• Table errors
• Missing list items
• Repeated paragraphs
• Copy-and-paste formatting problems
• Incorrect app names
• Incorrect plan names

The CMS version must be proofread separately from the document because publishing can introduce new errors.

21. Desktop QA

Step 42: Test the Desktop Page

Review the draft or preview on a standard desktop screen.

Check:

• Page title
• Header and navigation
• Featured image
• Introduction
• Quick verdict
• Table of contents where used
• Headings
• Paragraph width
• Line spacing
• Tables
• Screenshots
• Captions
• Pros and cons
• CTA
• Author section
• Reviewer section
• Footer
• Related content
• Breadcrumbs

Desktop Functional Checks

• All links work.
• CTA buttons work.
• Tables display correctly.
• Images load.
• Lightbox or zoom works where used.
• Expandable sections work.
• Forms work.
• No visual elements overlap.
• Sticky elements do not block content.
• The page does not create unexpected horizontal scrolling.

22. Mobile QA

Step 43: Test the Mobile Page

Mobile QA is mandatory.

Check:

• H1 readability
• Featured-image crop
• Quick-verdict layout
• Table behavior
• Screenshot readability
• Button size
• CTA layout
• Paragraph spacing
• Font size
• Line height
• Breadcrumb layout
• Author and reviewer cards
• Related-content cards
• Form fields
• Sticky CTA behavior where used
• Horizontal scrolling

Mobile Table Rules

When a table is wider than the screen:

• Use controlled horizontal scrolling.
• Keep important labels visible.
• Avoid cutting off data.
• Include a visual cue that the table can scroll.
• Consider replacing a complex table with mobile cards when necessary.

Mobile Screenshot Rules

Screenshots must remain readable without requiring excessive zoom.

23. Browser and Device Testing

Step 44: Test Across Browsers

At minimum, review the page in:

• A Chromium-based desktop browser
• A mobile browser
• Another major browser where resources permit

Check for:

• Layout differences
• Font issues
• Image problems
• Button behavior
• Table behavior
• Script errors
• Form errors

Critical pages may require broader device testing.

24. Accessibility QA

Step 45: Complete Accessibility Checks

Confirm:

• Heading hierarchy is logical.
• Images have appropriate alt text.
• Decorative images use appropriate empty alt text.
• Links have descriptive labels.
• Buttons have clear text.
• Text is readable against the background.
• Information is not communicated only through color.
• Tables use appropriate headers.
• Keyboard navigation works where applicable.
• Focus indicators remain visible.
• Expandable elements are usable.
• Form fields have labels.
• Error messages are understandable.

Accessibility Rule

Do not use design choices that make screenshots, tables, buttons, or text difficult to perceive or operate.

25. Performance QA

Step 46: Review Page Performance

Check:

• Image file sizes
• Image dimensions
• Lazy-loading behavior
• Embedded videos
• Third-party scripts
• Table scripts
• CTA scripts
• Page-builder elements
• Layout movement
• Mobile loading

Performance Rules

• Avoid uploading oversized images.
• Avoid unnecessary animation.
• Avoid multiple heavy embeds.
• Use a thumbnail or click-to-load approach for video where appropriate.
• Remove unused design elements.
• Do not delay publication for minor performance differences without context, but escalate serious problems.

Technical concerns should be reviewed by the developer.

26. Link and Functional QA

Step 47: Check Every Link

Verify:

• Internal links
• External links
• CTA links
• Author links
• Reviewer links
• Breadcrumb links
• Table-of-contents links
• Image links
• Related-content links
• Social-sharing links

Confirm:

• No 404 errors
• No staging URLs
• No document-edit links
• No tracking links exposing private information
• No incorrect redirects
• No unapproved affiliate links
• Correct link attributes

Step 48: Test Forms and Conversion Paths

If the article includes a form or links to a lead-generation page:

• Submit a test form.
• Confirm the success message.
• Confirm notification delivery.
• Confirm CRM or email routing where applicable.
• Confirm source attribution.
• Confirm the return path.
• Remove test submissions where necessary.

27. Final Pre-Publication Approval

Step 49: Complete the Pre-Publication Checklist

The responsible reviewers must approve their areas.

Design Approval

• Featured image approved
• Screenshots approved
• Tables approved
• Graphics approved
• Mobile layout approved
• Alt text and captions complete

Content Approval

• CMS content matches approved draft
• No factual changes
• No missing limitations
• Verdict remains accurate
• Disclosures are visible
• Author and reviewer details are correct

SEO Approval

• SEO title implemented
• Meta description implemented
• Slug approved
• H1 correct
• Internal links implemented
• Canonical correct
• Indexability confirmed
• Structured data validated
• Breadcrumbs correct

Technical Approval

• No major layout errors
• Page loads properly
• Forms work
• Buttons work
• No critical console errors
• Mobile behavior is acceptable
• Performance concerns are addressed

Project Approval

• All required checks complete
• Publication date confirmed
• Promotion handoff ready
• Tracking plan ready
• Content-refresh date recorded

Step 50: Record Final Approval

Record:

• Designer name
• Publisher name
• Content approver
• SEO approver
• Technical approver
• Project approver
• Approval date
• Scheduled publication date
• Remaining non-blocking notes

Approval Decisions

28. Publishing

Step 51: Schedule or Publish the Article

Confirm:

• Correct date
• Correct time
• Correct timezone
• Correct visibility
• Correct category
• Correct author
• Correct featured image
• Correct URL
• Correct social preview
• Correct site archive placement

The Project Manager should ensure that the article fits the approved publishing calendar.

Step 52: Confirm Sitemap and Feed Inclusion

After publication, confirm where relevant:

• The article appears in the XML sitemap.
• The article appears in the blog or category archive.
• The article appears in the RSS or content feed where applicable.
• The article is accessible from at least one internal page.
• The page is not orphaned.

The page should not depend only on sitemap discovery.

29. Post-Publication Verification

Step 53: Open the Live URL

Immediately after publication, open the live page in a new browser session.

Confirm:

• The URL works.
• The page returns the correct response.
• The page is publicly accessible.
• The title displays correctly.
• The featured image loads.
• The layout matches the approved preview.
• No draft labels appear.
• No staging links remain.
• No login is required.

Step 54: Repeat Critical Live Checks

On the live page, recheck:

• H1
• Quick verdict
• Pricing
• Screenshots
• Tables
• CTA
• Internal links
• External links
• Author information
• Reviewer information
• Disclosures
• Canonical
• Indexability
• Structured data
• Mobile display
• Social preview

A page that passed preview QA may still experience live-environment issues.

Step 55: Validate Structured Data

Use an appropriate validation tool to confirm:

• Markup is detected.
• Required fields are present.
• URLs are correct.
• Images are accessible.
• Author and publisher information are correct.
• Dates are correct.
• No unsupported ratings are marked up.
• No critical errors exist.

Warnings should be reviewed in context.

Step 56: Verify Search Console Readiness

Confirm:

• The page is not blocked.
• The canonical is correct.
• The page can be crawled.
• The URL inspection process does not show an obvious technical issue.
• The page is eligible for indexing.

Where appropriate, request indexing according to Blinto’s normal SEO process.

Requesting indexing does not guarantee immediate indexation.

Step 57: Check Analytics and Tracking

Confirm:

• Pageview tracking
• CTA click tracking
• Form tracking
• Scroll tracking where implemented
• Outbound-link tracking where relevant
• Event naming
• Campaign or source attribution

Record the publication date so performance can be measured accurately.

Step 58: Verify Social Preview

Test or review how the page appears when shared.

Confirm:

• Correct title
• Correct description
• Correct image
• Correct URL
• No old cached asset
• No cropped critical text

Fix social metadata where needed.

Step 59: Document Post-Publication Issues

Classify issues as:

Critical and high issues should be corrected immediately through the approved process.

30. ClickUp Requirements

Status Changes

At the beginning:

Content Approved for Design and Publishing → Design in Progress

After assets are ready:

Design in Progress → CMS Upload

After CMS implementation:

CMS Upload → Publishing QA

When corrections are required:

Publishing QA → Publishing Revision

After approval:

Publishing Revision → Approved to Publish

After publication:

Approved to Publish → Published

After live-page verification:

Published → Published and QA Verified

SOP 6 ends when the status reaches Published and QA Verified.

Required ClickUp Fields

• Final title
• Content type
• Primary keyword
• Final URL
• URL slug
• Designer
• Publisher
• Content approver
• SEO approver
• Technical approver
• Featured-image status
• Screenshot status
• Table status
• Alt-text status
• Internal-link status
• External-link status
• CTA status
• Schema status
• Canonical status
• Indexability status
• Desktop QA status
• Mobile QA status
• Accessibility status
• Publication date
• Live QA date
• Pricing verification date
• Recommended refresh date
• Analytics tracking status
• Final publication status

Required Attachments

• Final approved article
• Featured image
• Screenshot folder
• Graphic files
• Image and alt-text sheet
• CMS preview link
• Metadata record
• Internal-linking record
• Structured-data validation result
• Pre-publication checklist
• Desktop QA checklist
• Mobile QA checklist
• Accessibility checklist
• Final approval record
• Live URL
• Post-publication verification checklist
• Issue log

31. Recommended Timeline

Single App Review

Estimated total: 8–16 working hours

Comparison Article

Estimated total: 12–22 working hours

Category Review

Estimated total: 18–36 working hours

The timeline depends on the number of apps, screenshots, tables, custom graphics, and CMS complexity.

32. Quality Standards

A Shopify app review is ready for publication when:

• The live article matches the approved content.
• Visuals improve understanding.
• Screenshots are current and safe to publish.
• Tables are accurate and readable.
• Images are optimized.
• Alt text is complete.
• The URL is correct.
• Metadata is correct.
• Internal links support the content cluster.
• External links use reliable sources.
• The CTA is relevant and functional.
• Testing and commercial disclosures are visible.
• Author and reviewer information is accurate.
• Structured data reflects visible content.
• The canonical is correct.
• The page is indexable.
• Desktop and mobile QA are complete.
• Accessibility requirements are addressed.
• No critical technical errors remain.
• Analytics and CTA tracking work.
• Post-publication verification is complete.

33. Common Mistakes to Avoid

Do not:

• Start design before the article is approved.
• Use an older content version.
• Change the verdict during CMS upload.
• Hide important limitations in the design.
• Use low-quality or irrelevant stock images.
• Publish screenshots containing private data.
• Use outdated app screenshots.
• Upload oversized images.
• Use generic image filenames.
• Add keyword-stuffed alt text.
• Create unreadable mobile tables.
• Add unverified ratings to graphics.
• Add unsupported review schema.
• Use the wrong canonical.
• Publish with noindex enabled.
• Link to staging pages.
• Publish broken internal links.
• Add an unrelated CTA.
• Forget testing or affiliate disclosures.
• Assign an incorrect author.
• Update the publication date without meaningful changes.
• Skip mobile QA.
• Assume the preview and live page will behave identically.
• Publish without checking analytics.
• Complete the task before live-page verification.

34. Escalation Rules

Escalate to the Project Lead when:

• The final visual may violate third-party brand requirements.
• A screenshot contains sensitive information that cannot be removed safely.
• The CMS implementation changes the meaning of the content.
• A structured-data recommendation is unclear or risky.
• The page requires a major template change.
• The article conflicts with existing website architecture.
• The planned URL is already indexed for another page.
• A canonical conflict is identified.
• The article cannot be made mobile-friendly.
• A serious accessibility issue remains.
• The CTA or form does not work.
• Analytics cannot track the required actions.
• The article displays outdated pricing before publication.
• The app is rebranded, removed, or changed before launch.
• The founder requests design or wording changes that affect editorial independence.
• The live page contains a critical technical or factual issue.

The Project Lead may approve:

• Asset replacement
• Content reapproval
• URL change
• Template modification
• Technical development support
• Publication delay
• Article update
• Content cancellation

35. Definition of Done

SOP 6 is complete only when:

• The final approved handoff has been reviewed.
• The asset plan is complete.
• The featured image is approved.
• Required screenshots are prepared.
• Sensitive information has been removed.
• Supporting graphics and tables are complete.
• Image files are compressed and correctly named.
• Alt text and captions are complete.
• The final article is uploaded to the CMS.
• The approved content structure is preserved.
• The URL slug is approved.
• The SEO title is implemented.
• The meta description is implemented.
• Social metadata is implemented.
• Internal links are complete.
• External links are checked.
• The CTA is implemented and tested.
• Author information is correct.
• Reviewer information is correct.
• Testing and commercial disclosures are visible.
• Date information is correct.
• Appropriate structured data is implemented and validated.
• Breadcrumbs are correct.
• The canonical is correct.
• The page is indexable.
• Desktop QA is complete.
• Mobile QA is complete.
• Browser testing is complete.
• Accessibility QA is complete.
• Performance QA is complete.
• Form and link testing are complete.
• Final publishing approval is recorded.
• The article has been published.
• The live URL has been verified.
• Analytics and tracking are working.
• Post-publication issues have been resolved or recorded.
• ClickUp contains the live URL and publication record.
• The ClickUp status is Published and QA Verified.

If any blocking requirement is missing, the article has not completed SOP 6.

36. Handoff to SOP 7

After the article is published and verified, the Project Manager prepares the handoff for promotion, performance tracking, relationship building, and content maintenance.

Required Handoff Information

• Final article title
• Content type
• Live URL
• Publication date
• Primary keyword
• Search intent
• Target audience
• App or apps covered
• App founder or company details
• Testing level
• Main verdict
• Featured image
• Social-share image
• Approved promotional summary
• Internal-link opportunities still pending
• CTA goal
• Analytics event names
• Search Console tracking requirement
• Current ranking baseline
• Pricing verification date
• Recommended content-refresh date
• Founder-outreach eligibility
• Partnership disclosure status
• Known post-publication issues
• Publication owner
• Performance owner

The task then moves to:

SOP 7: Shopify App Review Promotion, Performance Tracking, and Content Maintenance

SOP 7 will define:

• Founder and app-company outreach
• Social and newsletter promotion
• Internal distribution
• Link and mention tracking
• Search performance monitoring
• Engagement and CTA tracking
• Lead and partnership attribution
• Content-format comparison
• Reporting cadence
• Pricing and feature updates
• Screenshot refreshes
• Content-decay monitoring
• App removal or rebrand handling
• Review refresh workflow
• Scale, improve, narrow, or pause decisions